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I.  INTRODUCTION 

Designed  to  be  a  flexible,  multirole  component  in  future  Navy  battle 
networks,  LCS’s  reconfigurable  modular  design  will  be  a  first  among 
Navy  combatants.  Indeed,  because  the  ship  is  so  different,  much  hard 
work  and  experimentation  still  need  to  be  done  to  unlock  its  full  potential. 

— Robert  O.  Work,  2014 

The  Littoral  Combat  Ship  (LCS)  is  an  evolving  platform  capable  of  performing 
missions  and  fulfilling  roles  in  a  variety  of  environments  throughout  the  world.  A 
combination  of  adaptable,  swappable  mission  packages,  as  well  as  the  ability  to  operate 
within  shallow  water,  enables  the  LCS  to  provide  support  to  partner  nation  and  U.S. 
assets  in  ways  that  were  once  inconceivable.  Naval  Surface  Forces  Command  has 
expressed  a  growing  interest  in  the  use  of  Wireless  Mesh  Networks  (WMN)  to  perform 
C2  functions  for  mission  areas  as  well  as  intelligence  and  data  collection.  The  value  of  a 
WMN  in  littoral  operations  is  the  ability  to  have  a  portable,  flexible  system  capable  of 
being  used  on  aerial,  surface,  subsurface,  manned,  and  unmanned  platforms.  For  the 
network  to  maintain  connectivity,  a  capable  platform  must  be  able  to  dispense  signals  to 
the  connected  nodes  reliably.  The  goal  of  this  research  is  to  discover  if  an  LCS,  operating 
in  littoral  environments,  is  capable  of  fulfilling  the  role  of  an  Internet  Gateway  (IGW), 
hub,  router,  or  network  bridge  to  surrounding  connected  nodes.  The  research  posits  to 
evaluate  data  gathered  from  real-world  events,  and  place  it  into  simulations  modeled  with 
equipment  and  nodes  available  in  the  CENETIX  Tactical  Network  Testbed  (TNT) 
located  in  San  Francisco  Bay  to  determine  WMN  performance.  The  research  seeks  to 
model  the  findings  from  observed  performance  using  Systems  Tool  Kit  (STK)  and 
QualNet  simulation  software.  The  research  culminates  in  a  recommendation  for  a 
network  structure  based  on  observed  performance. 

Advances  in  WMN  and  Mobile  Ad-Hoc  Network  (MANET)  technologies  are 
ringing  in  an  era  of  improved  warfighting  capabilities  for  the  naval  platforms  capable  of 
utilizing  them.  The  idea  of  Network  Centric  Warfare,  a  concept  proposed  over  a  decade 
ago  by  the  late  VADM  Cebrowski,  postulates  to  use  information- sharing  as  a  key  enabler 
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to  support  tactical  decision-making  across  the  spectrum  of  warfighting.  Data  networks 
used  to  support  information- sharing  are  the  backbone  of  any  tactical  decision  maker’s 
arsenal  of  tools  in  a  littoral  environment.  Without  such  networks  enabling  a  constant 
exchange  of  information  about  contacts  of  interest,  mission  objectives,  and  threats, 
overall  situational  awareness  (SA)  becomes  stale.  As  technology  improves,  the  current 
gap  between  cyber  and  physical  dimensions  in  the  littorals  will  eventually  be  bridged.  For 
this  to  happen,  the  network  architecture  and  bandwidth  needed  to  support  nodes,  in  the 
form  of  both  manned  and  unmanned  systems,  will  need  to  be  reliable  and  robust  enough 
to  operate  in  the  uncertain  conditions  of  the  littorals.  The  idea  of  using  mesh  networks  as 
a  means  to  gain  tactical  advantages  in  the  cyber-physical  domain  was  introduced  in  a 
U.S.  Naval  Institute  article  written  by  Dr.  Bordetsky  and  CAPT  (ret.)  Wayne  P.  Hughes 
in  2016  (Bordetsky,  Benson,  &  Hughes,  2016).  The  cornerstone  of  the  cyber-physical 
precept  is  that  mesh  networks  do  more  than  provide  passive  information  sharing,  they  are 
a  vital  component  of  tactical  decision-making  and  need  to  be  constantly  monitored  and 
managed  to  support  mission  functions. 

Previous  research  on  tactical  wireless  networks  conducted  at  the  Naval 
Postgraduate  School  identified  a  novel  framework  for  the  use  of  WMN  to  support  C2 
functions  through  the  use  of  network  management  tools  and  dynamic  node  placement.  A 
primary  finding  that  emerged  from  the  research  was  that  Navy  commanders  might  one 
day  need  to  employ  and  reposition  assets  within  a  wireless  mesh  network,  to  strengthen 
or  enable  network  support  to  overarching  mission  tasks  (Maupin,  2016).  Recent  research 
conducted  to  demonstrate  the  benefits  of  networked  systems  to  support  tactical  mission 
areas  included  work  in  the  TNT  as  well  as  testing  with  commercial  satellite  services  and 
equipment  overseas  (United  States  Seventh  Fleet,  2016). 

Trident  Warrior,  a  maritime  exercise  conducted  by  U.S.  7th  Fleet  (C7F) 
Commander’s  Initiative  Group  (CIG)  in  the  Pacific  in  2015  proved  that  one  readily 
available  platform  for  the  use  of  C2  enhancing  wireless  technology  is  the  LCS.  Pandarra 
Net,  an  experiment  conducted  during  the  exercise  with  the  support  of  Naval  Warfare 
Development  Command  (NWDC),  posited  to  connect  a  ship’s  network  to  commercially 
available  throughput  systems.  The  goal  of  the  experiment  was  to  test  the  integration  of 
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equipment  for  use  with  a  high-bandwidth  commercial  satellite  provider,  a  company 
known  as  the  Other  3  Billion  (03b),  as  well  as  to  connect  two  naval  vessels  through  4th 
generation  long-term  evolution  (4G  LTE)  devices.  Also,  the  experiment  tested  the 
effective  range  of  MANET  technology  integrated  with  4G  LTE.  The  results  of  the 
experiment  demonstrated  the  ability  of  USS  Fort  Worth  (LCS-3)  to  take  advantage  of 
improved  bandwidth  through  integration  with  onboard  network  architecture,  via 
connection  with  in-line  encryption  devices  used  on  the  ship’s  unclassified  network  (C7F 
CIG).  The  experiment  did  not  place  emphasis  on  network  reliability  and  instead  focused 
on  bringing  networking  systems  online  and  making  them  capable  of  communicating  with 
surrounding  assets  and  shore-side  relay  stations.  The  test  was  short  in  duration  and 
focused  on  end-to-end  system  functionality  rather  than  collecting  network  metric 
statistics.  Difficulties  with  obtaining  final  permission  from  higher  authority  to  connect 
commercial  devices  to  the  ship’s  network  early  in  the  experiment  resulted  in  less 
experimental  data  than  anticipated,  but  overall  it  did  prove  that  interconnection  of  a  naval 
network  system  on  an  LCS  with  a  commercial  satellite  provider  was  possible  (United 
States  Seventh  Fleet,  2016). 

The  data  available  from  experiments  conducted  during  Trident  Warrior  2015  in 
the  Pacific,  as  well  as  annual  WMN  and  MANET  experiments  performed  with  the  Naval 
Postgraduate  School’s  TNT  in  San  Francisco  Bay,  provide  a  foundation  for  experimental 
designs  using  network  simulation  software.  The  goal  of  such  simulations  is  to  create 
scenarios  with  an  LCS  equipped  with  commercially  available  wireless  technology  to 
observe  network  performance.  Two  commercially  available  software  programs  capable  of 
modeling  WMN  and  MANET  on  naval  vessels  are  Systems  Tool  Kit  (STK)  and  QualNet. 
QualNet  provides  protocol  and  network  management  within  a  wireless  domain  (Scalable 
Network  Technologies,  2016),  while  STK  is  interoperable  with  QualNet  and  provides 
real  world  positional  data  of  satellite  orbits  and  uses  a  geographic  coordinate  system  for 
inclusion  of  models  representing  network  nodes  in  land,  sea,  or  space  (Scalable  Network 
Technologies,  2016).  STK  contains  models  of  the  Freedom  and  Independence  variants  of 
the  LCS  as  well  as  unmanned  systems  and  other  naval  platforms.  STK  is  an  ideal  palette 
for  experiments  dealing  with  satellite  and  mesh  technology  on  an  LCS,  while  QualNet 
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provides  the  protocols  and  network  management  of  the  simulated  wireless  architecture. 
This  research  seeks  to  build  on  previous  studies  relating  to  the  reliability  and 
performance  of  tactical  wireless  network  performance  on  LCS  platforms. 

A.  MESH  NETWORKS  IN  LITTORAL  OPERATIONS 

The  word  “littoral'’  does  not  have  a  precise  definition  regarding  distance  from 
land  or  depth  in  the  water;  it  is  strictly  determined  by  regional  factors  such  as  continental 
shelf  length  and  high  and  low  tide  extremes.  The  terms  naval  personnel  are  most  familiar 
with  regarding  littorals  are  “brown-water”  and  “near-ashore,”  essentially  a  region  near 
enough  land  that  a  military  vessel  operating  in  this  area  can  project  mission  influence 
over  sea,  land  and  associated  airspace  domains.  The  Naval  Postgraduate  School  Littoral 
Operations  Center  refers  to  it  as  the  littoral,  or  “near  shore,”  is  where  “hydrography, 
geography,  commerce,  fishing,  mining,  boundaries,  maneuver  and  sustainment  issues 
converge,  complicating  both  the  Offense  and  the  Defense,  and  placing  exceptional 
demands  on  naval,  aerial,  and  land  forces  that  must  operate,  fight,  and  influence  events 
there”  (Naval  Postgraduate  School,  n.d.a.).  The  following  is  the  definition  of  littoral 
waters  in  Naval  Warfare  College  (NWC)  terminology,  as  defined  by  Dr.  Milan  Vego: 
“Littorals,  properly  speaking,  encompass  areas  bordering  the  waters  of  open  peripheral 
seas,  vast  archipelagoes,  and  enclosed  and  semi-enclosed  seas.  Littorals  bordering  open 
oceans,  such  as  the  coasts  of  North  and  South  America,  Africa,  and  India,  extend  outward 
to  the  farthest  extent  of  the  continental  shelf’  (Vego,  2015,  p.  13). 

Littoral  waters  are  often  hallmarked  by  significant  physical  features  protruding 
from  the  ocean  floor,  such  as  visible  rock  formations,  extending  out  from  or  centering  on 
an  island  or  landmass.  These  features  can  affect  a  friendly  vessels  radar  and  line-of-sight 
RF  propagation  paths  through  diffraction  or  absorption,  as  well  as  by  concealing  smaller, 
potentially  threatening  Fast  Attack  Craft  (FAC)  or  Fast  Inshore  Attack  Craft  (FIAC)  that 
may  not  have  posed  a  threat  in  open  water,  but  gain  an  advantage  when  concealment 
grants  them  a  more  advantageous  time  and  distance  vector.  The  deltas  of  rivers  emptying 
into  the  ocean  can  also  be  avenues  of  approach  for  smaller  threat  vessels.  Near  ports  in 
industrialized  countries,  these  waters  experience  heavy  traffic  from  merchant  and 
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freighter  traffic  that  can  also  inhibit  SA.  FAC  and  FIAC  capable  of  posing  threats  to 
friendly  vessels  can  make  use  of  radar  clutter  created  by  large  commercial  vessels  to 
conceal  their  positions.  In  addition  to  traditional  seaborne  threats,  a  friendly  vessel,  such 
as  an  LCS,  has  the  potential  to  be  targeted  by  terrestrial  anti-ship  missile  platforms.  In  the 
book  Fleet  Tactics  and  Coastal  Combat ,  the  famous  quote  from  Lord  Nelson,  “A  ship  is 
a  fool  to  fight  a  fort”  (Hughes,  2014),  is  intended  to  describe  the  challenges  faced  by 
vessels  operating  in  the  littorals.  In  the  context  of  modern  day  weapons,  a  “fort”  can  be 
anything  from  mobile  launch  sites  to  stationary  defenses  with  sufficient  range  to  target 
vessels  operating  in  the  open-ocean  or  littorals.  There  may  be  little  an  LCS  can  do  to 
defend  itself  against  a  sudden  attack  by  one  of  these  anti-ship  defenses,  so  it  is  imperative 
that  SA  be  shared  between  allied  platforms  through  C4I  enhancing  networks  to  reduce 
risk.  Whenever  friendly  manned  or  unmanned  platforms  are  sharing  information,  they 
must  have  a  network  structure  to  support  it. 

Information  sharing  through  network  nodes  required  to  mitigate  the  risk  of 
asymmetric  threats  forms  one  of  the  precepts  of  Network-Centric  Warfare.  In  Littoral 
Combat  Ship:  An  Examination  of  its  Possible  Concepts  of  Operation,  a  study  conducted 
by  the  Center  for  Strategic  and  Budgetary  Assessments  (CSBA),  the  precepts  that  VADM 
Cebrowski  and  ADM  Clark  advocated  were  rephrased  in  the  following  paragraph: 

Engagement  on  the  seaward  side  of  the  littoral,  however,  including  the 
protection  of  the  main  battle  force  and  the  destruction  of  enemy  coastal 
naval  assets  such  as  mines,  submarines,  Fast  Attack  Craft  (FACs)  and  Fast 
Inshore  Attack  Craft  (FIACs),  would  be  undertaken  by  small  networked 
combatants.  (Murphy,  2014) 

Smaller  networked  combatants  include  a  combination  of  manned  and  unmanned 
systems.  The  use  of  the  ECS  as  a  sensory  platform  to  help  paint  the  broader  contact 
picture  within  the  littorals  is  the  emphasis.  The  document  also  addresses  the  fact  that  the 
ECS  does  not  have  long-range  air  defense  capabilities  to  reduce  its  vulnerability  as  an 
independently  operating  standalone  platform  within  known  hostile  environments.  As 
such,  an  LCS  requires  the  air  defense  umbrella  of  a  Surface  Action  Group  (SAG)  or 
Carrier  Strike  Group  (CSG)  in  times  of  conflict  or  heightened  tensions. 
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A  mesh  network  is  exactly  the  kind  of  force  multiplier  needed  to  give  an  edge  to 
Allied  tactical  decision-makers  using  the  Sense-Decide-Act  framework,  as  well  as  to 
offset  a  potential  adversary’s  decision-making  capabilities.  In  the  spirit  of  Distributed 
Lethality  (DL),  the  uncertainty  of  offensive  and  defensive  capabilities  presented  by 
friendly  manned  and  unmanned  assets  utilizing  the  mesh  has  the  potential  to  make  an 
adversary  expend  valuable  time  and  ISR  resources  in  determining  false  threats  from 
actual  ones.  This  technology  affords  allies  more  decision-making  time  and  enables 
offensive  strike  capabilities  from  platforms  that  an  adversary  may  overlook. 

In  an  article  published  by  Dr.  Bordetsky,  Steve  Benson  and  Wayne  Hughes,  on 
the  U.S.  Naval  Institute  Blog  in  2016,  the  concept  of  using  a  mesh  network  in  the  littorals 
to  improve  weapons’  reach  and  information  sharing  of  manned  and  unmanned  assets  is 
espoused.  The  article  further  clarifies  that  in  this  environment,  “The  threat  of  sudden, 
short-ranged  attack  is  of  constant  concern”  and  development  of  a  network  that  enables  us 
to  “Effectively  Attack  First”  is  of  paramount  importance  to  commanders  for  the 
integration  of  all  naval  operations  and  tactics.  The  framework  used  to  present  advantages 
offered  by  mesh  networks  in  decision-making  is  Sense-Decide-Act.  The  “sense” 
component  refers  to  visual,  electronic,  or  any  other  means  of  discovering  and  tracking  an 
adversary’s  whereabouts.  The  “decide”  portion  is  making  the  tactical  call  and  beginning 
to  enact  it  through  communications.  The  “act,”  in  this  context,  is  firing  a  weapon  at  the 
target  (Bordetsky  et  al.,  2016). 

An  LCS  is  among  the  primary  components  of  a  mesh  network  employed  in  this 
environment.  Theoretically,  an  LCS  equipped  with  a  mission  module — or  other 
adequately  suited  communications  equipment — capable  of  allowing  it  to  communicate 
with  nodes  within  the  mesh,  then  it  offers  a  potential  expansion  to  Command  and  Control 
(C2)  capabilities  within  the  global  littorals.  In  such  a  scenario,  the  LCS  could  perform 
many  functions.  For  instance,  it  may  act  as  a  major  node  between  assets  within  the 
network,  serving  as  a  router,  bridge,  or  hub.  Unmanned  systems,  as  well  as  other  remote 
systems,  may  need  a  single  platform  capable  of  relaying  and  translating  routing  protocols 
and  target  information  to  obtain  firing  solutions,  or  at  the  very  least,  share  SA. 
Admittedly,  not  all  LCS  vessels  would  be  employed  as  the  central  C2  platform  in  a  given 
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mesh  network,  as  this  would  allow  adversaries  a  greater  amount  of  targeting  certainty  to 
degrade  or  eliminate  the  mesh  network. 

B.  RESEARCH  OBJECTIVES 

The  purpose  of  this  research  will  be  to  evaluate  the  effectiveness  of  an  LCS  as  a 
major  node  in  a  WMN.  Based  on  analysis  of  a  simulated  LCS  operating  in  the  cluttered 
San  Francisco  Bay  environment,  a  generalized  conclusion  will  be  drawn  as  to  this 
platform’s  suitability  to  serve  as  a  critical  wireless  networking  node  within  a  littoral 
environment.  The  percentage  of  network  availability  time  used  with  US  Vs  and  other 
participating  units  will  be  used  to  observe  whether  or  not  the  LCS  is  a  platform  capable 
of  providing  reliable  services  necessary  to  maintain  a  flexible  mesh  network  among 
various  nodes.  The  research  also  postulates  to  identify  whether  network  management 
software  can  assist  in  identifying  how  an  LCS  can  best  serve  in  a  WMN  role.  The  use  of 
network  management  software  and  the  analysis  of  LCS  WMN  interoperability  with  other 
nodes  in  a  simulated  environment  will  be  the  starting  point  to  determine  if  the  vessel  can 
adequately  provide  the  network  capabilities  needed  to  support  mission  areas  throughout 
the  U.S.  Navy  and  DOD.  The  implications  of  WMN  for  use  in  U.S.  Navy  missions  is 
profound,  and  the  research  aims  to  form  one  of  the  initial  steps  in  determining  the 
usefulness  of  this  architecture  for  sea-going  as  well  as  aerial  and  terrestrial  platforms 
operating  in  the  littorals.  The  primary  questions  of  this  research  are: 

How  well  can  the  LCS  platform  perform  as  a  WMN  node  in  a  littoral 
environment  with  Unmanned  Surface  Vessels  (USV)  and  other  nodes? 

How  can  network  management  software  assist  in  identifying  the 
optimal  role  of  the  LCS  platform  in  a  WMN? 

C.  SCOPE  AND  LIMITATIONS 

This  thesis  research  has  the  potential  to  demonstrate  improved  C2  capabilities  for 
LCS  platforms  as  well  as  the  US  Vs  and  other  nodes  connected  to  it.  The  research  does 
not  seek  to  make  a  recommendation  for  a  specific  type  of  commercial  satellite  equipment 
to  be  used  on  the  LCS.  An  LCS  performing  as  an  Internet  Gateway  (IGW)  will  be 
assumed  to  be  equipped  with  a  maritime  terminal  and  subscription  or  mission  package 
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capable  of  fulfilling  this  role.  Although  the  research  does  not  analyze  the  C2  decision¬ 
making  processes,  having  the  means  to  communicate  over  a  WMN  is  a  critical  enabler. 

The  simulation  portion  of  this  research  seeks  to  model  equipment  that  has  been 
previously  used  in  experiments  within  the  SF  TNT  as  well  as  the  Trident  Warrior  2015 
exercise.  The  parameters  for  the  equipment  that  were  used  in  these  exercises  will  be 
employed  in  the  simulation  software,  with  the  LCS  being  the  primary  node  in  any 
simulated  scenario,  whether  performing  as  a  gateway,  bridge,  hub,  or  router.  Simulated 
packets  will  be  used  that  closely  match  real-world  throughput  in  each  scenario.  The 
research  does  not  examine  how  these  packets  would  pass  through  the  long-haul  system  to 
Navy  Network  Operating  Centers  (NOC)  on  the  shore  side,  as  the  network  architecture  in 
these  sites  may  have  bandwidth  limitations  imposed  by  policy  and  inline  equipment. 

The  final  determination  on  whether  an  LCS  can  perform  as  a  major  node  in  a 
WMN  will  take  into  account  the  network  performance  and  limitations  based  on  the 
number  of  connected  nodes.  The  findings,  if  positive  results  are  observed  from 
simulations,  will  contribute  to  further  field  experimentation  on  LCS  platforms  in  other 
networking  environments. 

D.  ORGANIZATION  OF  THESIS 

Chapter  II  provides  background  and  literature  review  of  research  and  concepts 
relevant  to  the  objectives.  Chapter  III  covers  the  research  design  to  be  used  in  QualNet 
and  STK  simulation  software.  Chapter  IV  is  an  overview  of  the  simulation  results  and 
provides  analysis  of  the  data  collection.  Chapter  V  summarizes  the  findings  and  makes 
recommendations,  as  well  as  future  areas  of  research  on  the  subject  matter. 
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II.  LITERATURE  REVIEW 


A.  NETWORK  NODE  TERMINOLOGY 

The  basis  of  any  discussion  on  network  nodes  and  operations  invariably  begins 
with  the  7-Layer  Open  System  Interconnection  (OSI)  model.  Figure  1  displays  the  basic 
OSI  model. 


Figure  1.  OSI  Model.  Source:  Edwards  (2009). 
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The  OSI  model  defines  how  data  packets  are  managed,  translated,  and  displayed 
by  information  systems.  In  the  context  of  this  thesis,  the  seven  layers  all  pertain  to  how 
an  LCS  can  perform  as  a  major  node  in  a  wireless  network.  With  this  in  mind,  the  layers 
primarily  addressed  in  this  thesis  are  the  Physical  through  Transport  layers.  The  injection 
of  application  software  into  simulations  may  be  possible  but  is  beyond  the  scope  of  this 
research.  A  predetermined  data  bit  rate  over  a  prescribed  length  of  time  will  be  used  for 
each  of  the  nodes. 

The  ability  of  an  LCS  to  perform  as  an  IGW,  router,  hub,  and  bridge  will  be 

measured  primarily  by  its  performance  with  connected  nodes.  A  network  node,  as  defined 

in  Network  Management  2nd  Edition,  is  a  component  at  either  end  of  a  network  link.  The 

definition  of  a  gateway,  router,  hub,  and  bridge  are  also  from  Network  Management  2nd 
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edition  (Subramanian,  2011).  The  first  term,  gateway,  is  a  component  that  connects  two 
independent  networks.  An  LCS  performing  as  an  Internet  Gateway  is  serving  the  gateway 
function  between  its  internal  network  and  the  shore- side  Internet  architecture.  The  second 
term,  router,  is  a  component  that  routes  data  packets  by  using  definitions  in  pre- 
established  or  learned  routing  tables.  The  ability  to  adapt  makes  router  self-healing,  as  it 
can  find  new  routes  if  a  transfer  path  is  lost  or  added.  A  router  can  interface  between 
mediums,  in  particular,  with  wired  and  wireless  connections.  The  LCS  will  perform  as  a 
router  between  manned  and  unmanned  assets.  The  third  term,  hub,  is  a  component  used 
to  repeat  data  or  signals  in  a  network.  The  LCS  will  perform  as  a  hub  when  receiving 
MIO  data  from  the  shore  side  and  indiscriminately  distributing  it  to  friendly  vessels 
within  range.  The  final  term,  bridge,  is  a  component  that  interconnects  Local  Area 
Networks  (LAN)  without  transmitting  unnecessarily  to  LANs  that  do  not  require  specific 
packet  information.  It  can  also  be  configured  as  a  tool  for  protocol  conversion,  due  to  its 
ability  to  store  and  forward  information.  The  LCS  will  perform  as  a  bridge  by  sending 
data  packets  on  mission  critical  information  to  unmanned  assets  incapable  of 
communicating  with  one  another. 

1.  LCS  Wireless  Network  Equipment  (Theoretical) 

In  the  simulated  scenarios,  the  LCS  will  serve  as  the  Internet  gateway  and  will 
require  the  right  network  equipment  and  routing  protocols  for  it  to  function  as  such.  The 
shipboard  Automated  Digital  Network  System  Increment  III  router  (ADNS  INC  III)  will 
be  configured  for  the  ad  hoc  routing  protocols  Optimized  Link  State  Routing  (OLSR), 
and  Ad  Hoc  On-Demand  Distance  Vector  (AODV)  and  a  SPAWAR  approved  wireless 
access  point  will  be  added  to  the  communication  suite  as  well.  Research,  Development 
and  Test  -  Navy  explains  that  ADNS  INC  III  has  the  following  features: 

•  Combines  all  Navy  tactical  voice,  video,  and  data  requirements  into  a 
single  IP  data  stream. 

•  Operates  with  higher  bandwidth  satellites,  supporting  up  to  25  Mbps  on 
unit  level  ships  and  up  to  50  Mbps  on  force  level  ships. 

•  Incorporates  an  IPv4/IPv6  dual  stack  and  ciphertext  security  architecture 
to  align  to  joint  and  coalition  networks.  (RDT&E  Navy,  2011,  p.  226) 
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ADNS  INC  III  will  serve  as  an  ideal  integration  point  for  WMN  and  MANET 
technologies. 


OLSR  is  the  first  routing  protocol  for  which  interfaces  need  to  be  configured. 
Thoroughly  described  in  RFC  3626,  OLSR  has  the  following  features  that  make  it 
suitable  for  the  scenarios  detailed  later  in  the  thesis. 

•  Proactive  routing  protocol  used  in  MANETs  that  has  routes  available 
when  necessary. 

•  Helps  minimize  the  overhead  from  flooding  of  control  traffic  using 
multipoint  relays  (MPR)  to  retransmit  control  messages. 

•  Only  requires  a  partial  link  state  to  be  flooded  to  provide  shortest  path 
routes. 

•  Reduces  the  maximum  time  interval  for  periodic  control  message 
transmission. 

•  Maintains  routes  to  all  network  destinations. 

•  Designed  to  work  in  a  distributed  manner  that  does  not  require  control 
from  a  central  entity. 

•  Does  not  require  sequenced  message  delivery,  and  each  control  message 
contains  a  sequence  number  for  each  message.  (Clausen  &  Jacquet,  2003, 
P-  7-8) 

The  next  protocol  used  is  AODV,  which  is  primarily  for  mobile  nodes  in 
MANETs.  As  explained  in  RFC  3561,  AODV  has  the  following  features: 

•  Rapid  adaptation  to  dynamic  link  conditions. 

•  Low  processing  and  memory  overhead. 

•  Low  network  utilization. 

•  Determines  unicast  routes  to  destinations  within  the  ad  hoc  network. 

•  Use  of  destination  sequence  numbers  ensures  constant  loop  freedom. 

•  Requesting  nodes  select  destination  with  the  higher  sequence  number 
when  choosing  between  two  routes. 

•  Enables  dynamic,  self-starting,  multi-hop  routing  between  participating 
mobile  nodes  attempting  to  connect  to  an  ad  hoc  network. 


11 


•  Nodes  can  quickly  obtain  routes  to  destinations  even  if  they  are  not 
actively  communicating. 

•  Notify  affected  nodes  of  broken  links  and  will  invalidate  the  routes. 
(Perkins,  Belding-Royer,  &  Das,  2003,  p.  1-2) 

The  AODV  protocol  is  critical  in  ensuring  network  communications  paths  are  always 
available  for  participating  nodes,  and  is  particularly  important  if  the  nodes  are  mobile. 

2.  Persistent  Systems  Wave  Relay 

To  achieve  wireless  connectivity  Persistent  Systems  Wave  Relay  (PSWR)  radios 
and  Quad  Radio  Routers  will  be  utilized  on  both  the  LCS  and  participating  nodes  to  form 
the  MANET  in  the  simulated  scenarios.  PSWR  is  designed  to  maintain  connectivity 
between  multiple  mobile  nodes.  The  technology  differs  in  its  ability  to  scale  to  a  network 
incorporating  high  numbers  of  moving  nodes  in  an  any-to-any  topology,  which  allows 
every  node  to  communicate  with  each  other  thus  enabling  true  peer-to-peer  connectivity. 
Forming  a  MANET  including  PSWR  radios  also  gives  the  advantage  of  maintaining 
routes,  and  detecting  changes  to  the  network  while  mobile,  which  will  be  the  case  in  the 
simulations  found  in  this  research.  The  proprietary  Wave  Relay  algorithms  excel  in  an 
environment  utilizing  mobile  nodes,  and  maintaining  routes  in  a  highly  scalable  network 
is  the  foundation  of  this  technology  (Persistent  Systems,  2012).  The  Wave  Relay  Man 
Portable  Efnit  Gen  4  (MPU4)  is  displayed  in  Figure  2. 
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Figure  2.  Wave  Relay  Man  Portable  Unit  Gen  4.  Source: 
Persistent  Systems  (2014c). 


In  addition  to  Wave  Relay  Radios,  Quad  Radio  Routers  will  be  required  on 
certain  nodes  to  form  the  MANET.  Similar  to  the  radios,  these  routers  excel  in  an 
environment  with  mobile  nodes.  Their  ruggedized  designs  are  adaptable  for  a  variety  of 
land  and  maritime  platforms,  and  they  are  critical  pieces  of  equipment  in  these  scenarios. 
Like  the  Wave  Relay  radios,  the  Quad  Radio  Routers  operate  at  OSI  layer  2  using  the 
same  proprietary  multicast  algorithms.  The  routers  are  scalable,  allowing  the  creation  of 
peer-to-peer  networks  providing  data,  video,  and  voice  in  severe  environments.  For  the 
nodes  that  utilize  the  router,  there  are  multiple  mounting  options  available.  They  can  also 
be  used  in  vehicles  for  land-based  nodes  or  mounted  to  the  mast  of  an  LCS  for  coverage 
over  larger  geographic  areas.  When  paired  with  a  tracking  antenna  system  kit,  the  routers 
are  capable  of  providing  long-range,  air-to-ground  connectivity  (Persistent  Systems, 
2016).  The  Quad  Radio  Router  is  displayed  in  Figure  3. 
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Figure  3.  Quad  Radio  Router.  Source:  Persistent  Systems  (2016). 
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Detailed  specifications  for  the  Quad  Radio  Router  are  found  in  Figure  4. 


Figure  4.  Wave  Radio  and  Quad  Radio  Router  Specifications.  Source: 
Wave  Relay  5  Integration  Unit  Technical  Specs  (2013). 


3x3  MIMO 
TECHNOLOGY 

Extended  Range 

1 50  Mbps  of  throughput 

Maximal  Ratio  Combining 

Spatial  Multiplexing 

Antenna  Detection 

MODULAR  RADIO 

RF  Modulations:  OFDM  (64-QAM,  16-QAM,  QPSK,  BPSK) 

6W  Transmit  Power* 

Swappable  Radio  Modules/Radio  Boards 
•RF-100Q/RF-1 100  -  L-Band  Frequency  Range:  13S0  - 1390  MHz* 
•RF-2000/RF-2 1 00  -  S-Band  Frequency  Range:  2200  -  2500  MHzt 
•RF-3000/RF-3100-C-Band  Radio  in  Development 

Software  configurable  bandwidths:  2.5  MHz,  5  MHz,  10  MHz,  20 

MHz,  40  MHz 

TX/RX  Operatinq  Modes:  All  modes  from  SISO  to  3x3  MIMO 

RolP 

Legacy  Radio  Tethering 

Legacy  Radio  Detection 

USB  Host /RS-232  Serial 

VIDEO 

HD-BNC  Connection 

3G-SDI  &  Composite  Input 

Integrated  HD  H.264  Video  Encoding/Decoding 

GPS 

33V  Active 

Situational  Awareness 

Cursor-on- Target  Compliant 

1  Second  Updates 

PTT/EUD 

Dual  Active  PIT  Channels 

End  User  Device  (EUD)  Data  /  Charging 

USB  Host /RS-232  Serial 

HD  Video  Output 

DATA 

USB  On-the-Go 

RS-232  Serial 

Ethernet 

H  D  Video  Input 

BATTERY 

Low  Battery  Alert 

Standard  Twist-Lock  Connector 

NETWORKING 

Advanced  multicast  algorithms 

Seamless  Layer  2  network  connectivity 

Integrated  serial-to-Ethernet  capability 

Cloud  Relay" 

DLEP  Certified 

IPv4  and  IPv6  compatible 

Integrated  DHCP  server 

USB  RNDIS  Host  and  Device 

SECURITY 

Integrated  Hardware  Cryptographic  Acceleration 

CTR- AES-256  Encryption 

HMAC-SHA-256  Authentication  &  Integrity 

Utilizes  Su'ite-B  Algorithms 

Cryptographically  authenticated  Over-the-Air  Rekey  and  Key  Zero 
FIPS  140-2  Level  1 

Rechargeable  30  Day  Hold-Up  for  Keys  and  Configuration  Settings 

PHYSICAL 

IS  x  2.6  x  4.7  inches/ 38.1mm  x66mmx  1 19.4mm  (NO  BATTERY! 

SPECIFICATIONS 

1 S  x  2.6  x  7.9  inches  /  3&  1  mm  x  66mm  x  200.7mm  (WITH  BATTERY) 

1 73  oz  /  490.5  grams  (NO  BATTERY) 

29.6  oz/ 839.1  grams  (WITH  BATTERY) 

MANUFACTURING  & 

ISO  900 1:2008  certified 

ENVIRONMENTAL 

Manufactured  to  M1L-STD  specifications 

IP68 

Coated  to  meet  MIL-C-64159  /  MIL-C-53039A(2)  standards 

Operating  temperature:  -40"  to  85"  C  /  -40’  to  1 BS’  F 

15 


The  next  piece  of  hardware  utilized  will  be  Persistent  System  Sector  Array 
Antennas,  which  connect  to  the  Quad  Radio  Routers.  The  antennas  provide  long-range, 
omnidirectional  coverage  capable  of  maintaining  maximum  throughput  for  multiple 
connections.  Each  Sector  Array  antenna  houses  three  individual  antennas,  providing  360- 
degree  coverage  and  each  antenna  covers  a  120-degree  area,  directing  transmissions  in  a 
manner  which  minimizes  interference  while  providing  optimal  connectivity  for  network 
nodes.  Utilizing  a  vertical  beam  width,  the  Sector  Array  Antenna  is  ideal  for  land-based 
and  maritime  networks,  allowing  uninterrupted  connections  in  even  the  most  challenging 
environments  (Persistent  Systems,  2014b).  This  powerful  antenna  enhances  the  feature 
set  of  the  MPU-4  and  Quad  Radio  Router  and  includes  the  following  features  and 
capabilities. 

•  Wave  Relay  MANET  routing 

•  Cursor-on-Target  compatible 

•  Wave  Relay  over  IP  (WRoIP) 

•  Operates  on  2.4  and  5  GHz  sector  arrays 

•  OFDM  with  Adaptive  Modulation  Algorithms 

•  Variable  channel  widths  of  5,  10,  20  or  40  MHz 

•  Multiple  RF  band  support 

•  Peer  to  peer  with  other  Quad  Radio  Routers  and  MPU  4s 

•  10-mile  range  on  both  the  2.4  and  5  GHz  variants  (Persistent  Systems, 
2014b) 

Each  antenna  includes  an  integrated  hardware  cryptographic  accelerator,  is  FIPS 
140-2  compliant,  support  AES-CTR-256  with  SHA-512  HMAC  encryption  and  over  the 
air  rekeying.  Configuration  management  is  accomplished  using  the  secure  web  interface 
or  the  network-wide  configuration  functionality  (Persistent  Systems,  2014b).  The 
combination  of  the  Quad  Radio  Router,  MPU4s  and  Sector  Array  Antennas  provide  a 
robust  solution  to  form  WMN  and  MANETs  for  multiple  mission  configurations  that  can 
be  managed  from  an  LCS  in  multiple  configurations  that  will  be  simulated  in 
forthcoming  sections  of  the  thesis.  The  Sector  Array  Antenna  is  displayed  in  Figure  5. 
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Figure  5. 


Sector  Array  Antenna.  Source:  Persistent  Systems  (2014b). 
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Utilizing  the  MPU4s,  Quad  Radio  Routers  and  Sector  Array  Antennas  allow  for 
the  natural  formation  of  a  WMN  or  MANET  based  around  an  LCS  as  a  major  node  and 
the  hardware  provides  the  flexibility  required  for  expansion  as  necessary.  The  small 
hardware  footprint  makes  the  Persistent  Systems  equipment  attractive  options  for  both 
maritime  and  aerial  use.  As  shown  in  Figure  7,  the  Wave  Relay  technology  uses  the 
random-access  protocol  carrier-sense  multi-access  with  collision  avoidance  (CSMA/CA) 
as  the  basis  for  wireless  networks.  Additionally,  Wave  Relay  uses  3x3  multiple-input- 
multiple-output  (MIMO)  technology  capable  of  delivering  up  to  150  Mbps  of  throughput 
at  varying  distances  (Pothitos,  2015).  Furthermore,  the  cloud  relay  serves  as  a  solution  to 
bridge  beyond  line  of  sight  (BFOS)  to  line  of  sight  (FOS)  networks.  Cloud  relay 
technology  allows  long-range  remote  access  to  video,  voice,  and  data  to  and  from  all 
MANETs.  It  also  provides  seamless  transition  via  layer  3  networks  to  other  connected 
MANETs  worldwide.  Existing  infrastructure  is  used  to  extend  the  MANET  including 
LTE,  SATCOM,  wired  Internet  and  other  layer  3  technologies  (Persistent  Systems, 
2014).  The  configuration  allows  for  easy  participation  in  a  MANET  from  the  sea,  air  or 
land  as  shown  in  Figure  8.  Wave  relay  and  cloud  relay  technologies  provide  the  means  to 
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easily  maintain  a  MANET  that  provides  more  than  adequate  throughput  for  operational 
purposes.  Potential  Cloud  Relay  Group  configurations  are  displayed  in  Figure  6. 


Figure  6.  Cloud  Relay  Groups.  Source:  Persistent  Systems  (2014a). 
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3.  Tsunami  QB-10100  Series  Wireless  Network  Bridge 

The  Tsunami  QB-10100  series  wireless  bridge  provides  near  line-of-sight,  point- 
to-point  connectivity  between  networks.  The  equipment  operates  in  the  5.150-5.925  GHz 
frequency  range  and  is  capable  of  delivering  600  Mbps  throughput.  Similar  to  PSWR,  it 
uses  OFDM  to  enable  flexible  RF  propagation  and  channels.  Proxim  Wireless,  the 
company  that  manufactures  the  equipment,  describes  it  as  having  the  following  key 
features: 

•  Suitable  for  Service  Providers,  Enterprises,  and  Governments 

•  Fully  integrates  within  ProximVision®  Advanced  Cloud-Based  Carrier 

•  Management  System  and  Controller 

•  Certified  for  deployments  in  the  Americas,  Europe,  and  Asia 

•  The  most  cost-effective,  very  high-performance  point-to-point  solution 
from  Proxim,  enabling  any  deployment  to  enjoy  a  quick  return  on 
investment  (Proxim  Wireless,  2016) 

B.  NETWORK  MANAGEMENT  AND  PERFORMANCE 

1.  Network  QoS  and  Availability 

Two  primary  factors  that  determine  the  performance  of  a  network  are  the  Quality 
of  Service  (QoS)  and  Availability.  QoS  refers  to  the  ability  of  a  network  to  run  or  deliver 
applications  commensurate  with  a  user’s  or  an  organization’s  expected  performance.  An 
example  of  acceptable  QoS  is  when  video  and  audio  are  streamed  without  interruption  at 
the  resolution  desired.  The  availability  of  a  network  refers  to  the  amount  of  up  or  down 
time  over  a  prescribed  period.  Many  organizations  use  the  “five  9s”  of  availability  as  a 
metric,  meaning  they  strive  for  the  highest  percentage  of  network  uptime  (West,  Dean  & 
Andrews,  2016).  Table  1  illustrates  availability  and  downtime  equivalents  and  sets  a 
metric  for  the  performance  of  the  LCS  as  a  major  node  in  a  wireless  network.  A  variety 
of  commercial  network  management  and  performance  monitoring  tools  are  available  to  a 
network  operator  to  determine  the  effectiveness  of  a  network.  A  description  of  some  of 
these  tools  is  described  in  upcoming  sections. 


19 


Table  1.  Availability  and  Downtime  Equivalents.  Source: 

West  et  al.  (2016). 


Availability 

Downtime/Day 

Downtime/Month 

Downtime/Y  ear 

99% 

14  minutes,  23 

7  hours,  18 

87  hours,  39  minutes,  29 

seconds 

minutes,  17  seconds 

seconds 

99.9% 

1  minute,  26 

43  minutes,  49 

8  hours,  45  minutes,  56 

seconds 

seconds 

seconds 

99.99% 

8  seconds 

4  minutes,  22 

52  minutes,  35  seconds 

seconds 

99.999% 

.4  seconds 

26  seconds 

5  minutes,  15  seconds 

2.  Network  Management  Tools 

The  proposed  software  suite  for  network  management  is  SolarWinds.  It  is  a  robust 
suite  of  software  that  will  provide  proper  oversight  of  the  network  using  the  Network 
Performance  Monitor  (NPM),  Network  Configuration  Manger  (NCM)  and  IP  Address 
Manager  (IP AM).  Software  of  this  type  is  critical  to  ensure  all  aspects  of  the  network  can 
be  monitored  especially  network  performance  of  the  Internet  gateway  and  connected 
nodes.  In  SolarWinds,  both  of  the  items  above  can  be  checked  using  the  network 
performance  monitor  and  NetFlow  traffic  analyzer.  Monitoring  traffic  is  critical  as 
bandwidth  will  likely  be  limited  in  most  operational  environments.  The  following 
features  will  be  used  from  the  LCS  to  manage  and  monitor  the  network. 

Network  Performance  Monitor  (NPM):  Customizable  topology  and 
dependency-aware  intelligent  alerts,  dynamic  wired  and  wireless 
discovery  and  mapping,  automated  capacity  forecasting,  alerting,  and 
reporting  and  wireless  network  monitoring  and  management.  (SolarWinds, 
n.d.d.) 
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A  screenshot  of  the  Network  Performance  Monitor  dashboard  is  displayed  in  Figure  7. 


Figure  7.  SolarWinds  Network  Performance  Monitor  Screenshot.  Source: 

SolarWinds  (n.d.d.). 


Network  Configuration  Manager  (NCM):  Multi-vendor  network  change  and  configuration 
management,  real-time  configuration  change  notification,  configuration  compliance  auditing, 
network  change  automation,  and  integration  with  NPM  (SolarWinds,  n.d.c.). 
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A  screenshot  of  the  Network  Configuration  Monitor  dashboard  is  displayed  in  Figure  8. 


Figure  8.  SolarWinds  Network  Configuration  Manager.  Source: 

SolarWinds  (n.d.c.). 
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IP  Address  Manager  (IPAM):  Automated  IP  address  management,  integrated  DHCP  and 
DNS  administration,  IP  alerting,  troubleshooting  and  reporting,  delegated  administration 
and  IP  detail  and  history  tracking  (SolarWinds,  n.d.a.). 


A  screenshot  of  the  IP  Address  Manager  is  displayed  in  Figure  9. 


Figure  9.  SolarWinds  IP  Address  Manager.  Source:  SolarWinds  (n.d.a.). 
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A  screenshot  of  the  NetFlow  Traffic  Analyzer  is  displayed  in  Figure  10. 


Figure  10.  SolarWinds  NetFlow  Traffic  Analyzer.  Source 

SolarWinds  (n.d.b.). 
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►  d  •  World  Wide  Web  HTTP  (80) 
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The  NetFlow  Traffic  Analyzer  (NTA)  provides  network  traffic  analysis  and 
bandwidth  monitoring.  It  is  capable  of  displaying  bandwidth  use  by  user,  application, 
protocol  or  IP  address  group  and  can  generate  customizable  network  traffic  reports.  One 
feature  that  will  be  particularly  useful  in  a  MANET  is  the  wireless  LAN  controller  traffic 
monitoring,  which  shows  the  applications  and  nodes  utilizing  bandwidth  on  a  wireless 
network.  Finally,  the  program  contains  network  traffic  forensics  for  analyzing  traffic 
patterns  over  periods  of  time  (SolarWinds,  n.d.b.). 

These  programs  provide  the  tools  necessary  to  effectively  monitor  a  MANET 
with  multiple  nodes  since  the  participating  units  will  not  always  be  a  fixed  number. 


23 


C.  PANDARRA  NET 

Pandarra  Net  took  place  in  two  phases.  Phase  I  focused  on  the  installation  and 
end-to-end  operation  of  the  network  infrastructure  on  LCS-3  and  USS  Warrior  (MCM- 
10)  to  transmit  data  over  a  4G  LTE  Network  designed  by  Oceus.  The  03b  (Other  3 
Billion)  long-haul  backbone  to  public  Internet  services  ashore  connected  to  a  Wi-Fi 
network  on  LCS-3.  This  connection  was  a  separate  network  from  NIPRNET  and  operated 
as  an  unclassified  (UNCLAS)  network.  The  Wi-Fi  and  4G  LTE  network  were  separate 
networks  that  could  not  communicate  with  one  another.  Thus,  the  Wi-Fi  network  on 
LCS-3  was  limited  to  traffic  on  that  ship,  and  could  not  function  as  a  repeater  to  transmit 
data  from  MCM-10  to  the  public  Internet. 

In  Phase  II,  LCS-3  connected  its  NIPRNET  to  03b’s  long-haul  system.  This 
connection  was  used  in  place  of  its  program  of  record  system  associated  with  the  Super 
High  Frequency  (SHF)  Commercial  Broadband  Satellite  Program  (CBSP).  The 
throughput  of  03B  was  expected  to  be  much  higher,  but  the  results  were  not  indicative  of 
this,  which  raised  other  concerns  about  whether  or  not  the  Navy’s  shore-side  network 
architecture  could  support  a  high-speed  bandwidth  provider.  It  is  an  issue  of  concern  but 
beyond  the  scope  of  this  research.  An  overview  of  both  phases  and  network  equipment  is 
shown  in  Table  2  and  Table  3. 
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Table  2.  Phase  I  and  II  Overview.  Source:  United  States 

Seventh  Fleet  (2016). 


Phase  I 

Phase  II 

03b  SATCOM  Integration 

with  ship’s  network 

None 

Passed  ship’s  SIPR  and 

NIPR  traffic 

Mobile  Device  integration 

with  ship’s  network 

None 

4G  LTE  connected  to  FTW 

Secret  network  via  a  file 

server 

03b  SATCOM 

UNCLAS  only;  Connected 

to  public  Internet 

Replaced  ship’s  existing 

SHF  SATCOM  Connected 

to  shore  SIPR  and  NIPR 

4G  LTE 

UNCLAS  only 

Secret  only 

Wi-Fi 

UNCLAS  only 

None 

CODA-LITE 

4G  LTE  and  Wi-Fi 

4G  LTE 

Pacstar  &  TACLANE 

No 

Yes 

MANET 

Yes 

No 
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Table  3.  Devices  Used  during  Pandarra  Net  in  Phase  I  and  II.  Source: 

United  States  Seventh  Fleet  (2016). 


Device 

Phase  I  Quantity 

Phase  II  Quantity 

Samsung  Note  II  cell  phones 

12 

5 

Dell  tablets  (Wi-Fi) 

4 

N/A 

Panasonic  TouchPads  (4G  LTE) 

N/A 

4 

HP  Laptop  supporting  LRTV 

1 

1 

HP  Laptops  for  Public  Internet 

Usage  (Wi-Fi  only) 

4 

N/A 

LRTV  (video  camera) 

1 

1 

1.  03b 

03b  is  a  commercial  satellite  company  that  launched  its  initial  constellation  of 
Medium  Earth  Orbit  (MEO)  satellites  in  March  2014.  A  technical  overview  of  satellites 
operated  by  the  company  is  as  follows:  they  currently  maintain  12  satellites,  each 
equipped  with  10  steerable  beams  for  customers  and  2  beams  for  IGW  ground  stations; 
the  channel  bandwidth  is  216  MHZ;  a  steerable  beam  covers  a  700  km  diameter  and  uses 
bent-pipe  topology  to  connect  customers  with  03b’ s  IGWs;  the  frequency  band  for 
downlink  is  17.7-20.2  GHz,  and  uplink  is  27.5-30  GHz  (Barnett,  2013).  Additional 
information  on  standard  operating  equipment  parameters  is  listed  in  Appendix  A.  The 
advantages  of  this  satellite  network  is  a  low  latency,  high  throughput  system  that  has 
achieved  downlink  speeds  upwards  of  400  Mbps  in  seagoing  environments.  One  of  the 
goals  of  the  company  is  to  provide  high-speed  data  rates  to  areas  of  the  world  where 
coverage  is  not  currently  available.  The  regions  of  the  world  currently  covered  by  03b’ s 
constellation  are  between  +/-  65  degrees  latitude;  it  claims  to  be  capable  of  servicing  over 
90%  of  DOD  facilities  and  AORs  with  this  coverage  (D’Ambrosio,  2015).  The  company 
has  worked  closely  with  DOD  agencies,  including  Space  and  Naval  Warfare  Systems 
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command  (SPAWAR).  03b’ s  field  experiments  range  from  those  conducted  with  U.S. 
Navy  assets  as  well  as  those  carried  out  with  Special  Forces  Command  (SOCOM)  and  the 
United  States  Marine  Corps  (USMC)  on  terrestrial  applications.  The  range  of  03b 
experimentation  may  be  a  precursor  to  eventual  DOD  acceptance  of  commercial  systems 
as  a  viable  alternative  or  supplement  to  Program- of-Record  systems. 

03b  envisions  it  will  one  day  provide  data  services  to  U.S.  Naval  platforms  at  50 
times  the  throughput  of  current  Super  High  Frequency  (SHF)  systems  in  use.  03b’ s 
satellite  constellation  utilizes  the  Ka-Band,  and  with  its  lower  orbits,  company 
stakeholders  claim  that  it  will  offer  better  latency  and  higher  data  speeds  than 
geostationary  satellites.  Improved  data  transfer  is  critical  to  the  success  of  the  LCS 
platform,  which  is  currently  equipped  with  aging  SHF  terminals,  and  relies  on  higher  data 
throughput  to  push  information  on  the  health  of  onboard  equipment  to  maintenance  teams 
on  the  shore  side  to  maintain  optimal  crew  manning.  Without  delving  into  the  many 
underlying  examples  of  how  an  LCS  requires  additional  bandwidth  when  compared  to 
other  USN  platforms  of  similar  design  and  mission,  it  is  safe  to  opine  that  increased  data 
throughput  and  availability  offers  advantages  across  the  spectrum  of  LCS  operations. 

Assuming  the  speeds  above  are  realistic,  an  LCS  would  be  well- suited  to  make 
use  of  03b ’s  technology  to  augment  its  data  needs  as  well  as  serve  as  an  IGW  to 
networked  nodes  in  its  operating  vicinity. 

2.  Oceus  Networks  4G  LTE 

Oceus,  similar  to  03b,  is  a  commercial  company  that  has  a  record  of  conducting 
proof-of-concept  network  and  communications  experiments  with  U.S.  Navy  assets.  In  an 
experiment  conducted  in  2013  with  Naval  Air  Systems  Command  (NAVAIR),  the  USS 
Kearsarge  and  USS  San  Antonio  were  able  to  use  4G  to  integrate  data  streams  between 
the  two  ships  as  well  as  deployed  aircraft  (Crowe,  2013).  The  system  used  microwave 
technology  to  create  wireless  wide-area  network  (WWAN)  connectivity  between  nodes 
(ships  and  aircraft)  and  enabled  individuals  to  connect  commercial  off-the-shelf  devices 
through  local  access  points  within  the  nodes.  Transfer  speeds  between  devices  were 
recorded  as  high  as  100Mbps  for  downlink.  For  4G  to  operate  effectively  within  the  hull 
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of  a  ship,  multiple  antennas  needed  to  be  installed  to  overcome  the  detrimental  effects  on 
RF  propagation  from  closed  hatches  and  thick  bulkheads.  An  LCS,  with  limited  real 
estate  for  antennas  on  its  superstructure  as  well  as  interior,  may  find  this  restrictive. 
However,  the  system  has  shown  its  effectiveness  at  sea  and  may  only  need  a  redesign  to 
make  it  a  viable  solution  for  communications  to  support  various  mission  areas.  The 
Oceus  4G  LTE  network  used  in  Pandarra  Net  2015  also  formed  a  MANET  for  small  boat 
operations,  demonstrating  a  practical  application  for  Visit  Board  Search  and  Seizure 
(VBSS)  missions  (Crowe,  2013). 

3.  Phase  I 

Pandarra  Network  in  Phase  I  consisted  of  three  main  components:  Wi-Fi,  Oceus 
Networks  4G  LTE  bubble,  and  03b  Satellite  services.  The  experiment  required  the 
installation  of  specialized  equipment  to  enhance  both  ships’  internal  and  external  network 
architecture.  The  installation  consisted  of  a  fiber-optic  cabling  architecture  developed  by 
SPAWAR,  known  as  the  Common  Optical  Digital  Architecture  (CODA)  Lite,  and 
wireless  node  access  points  that  were  able  to  form  an  UNCLAS  network  mostly  within 
the  skin  of  the  ship.  The  4G  LTE  network  was  used  to  connect  authorized  devices  to  this 
network — these  devices  are  listed  in  Table  2.  The  external  equipment  used  to  connect 
with  03b’s  MEO  satellites  consisted  of  two  1.2M  dishes,  displayed  in  Figure  11,  on  port 
and  starboard  sides  of  the  superstructure.  The  layout  of  the  entire  system  is  shown  in 
Figure  12.  Through  this  UNCLAS  network  on  the  LCS-3,  the  crew  was  able  to  connect  to 
the  Internet  via  approved  devices  and  conduct  high  bandwidth  transactions  such  as  video 
teleconferencing  with  family  members  back  home,  stream  live  video,  and  stream  high- 
definition  (HD)  subscription  services  such  as  Netflix. 
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Figure  11.  1.2M  03b  Radome.  Source:  D’Ambrosio  (2015). 


The  throughput  of  the  system  performed  as  well  as — if  not  better  than — expected 
by  the  NWDC  team.  On  the  UNCLAS  network  on  LCS-3,  the  crew  was  able  to  connect 
to  quality-of-life  (QoL)  Internet  services  without  stressing  bandwidth  limitations.  This 
ability  was  also  because  this  network  did  not  go  through  any  DOD  network  architecture 
on  the  shore-side,  it  went  through  03B’s  satellite  network  which  routed  it  to  the  public 
Internet  via  a  ground  station  in  Perth,  Australia. 

Figure  12.  Pandarra  Net  Configuration  in  Phase  I.  Source:  United  States 

Seventh  Fleet  (2016). 
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4. 


Phase  II 


Phase  II  encompassed  the  integration  of  LCS-3’s  NIPRNET  and  SIPRNET  with 
the  03b  long-haul  satellite  communications  system  via  connection  through  Pandarra  Net 
and  LC-3’s  shipboard  network.  The  network  configuration  is  displayed  in  Figure  13.  This 
phase  used  the  approved  4G  LTE  bubble — not  to  be  confused  with  Wi-Fi — to  attempt  to 
connect  SIPRNET  to  the  shore-side  through  03b’ s  backbone.  The  4G  LTE  could  have 
also  been  configured  to  connect  NIPRNET  through  03b  ’s  backbone,  but  it  would  have 
required  separate  routers  and  equipment  to  prevent  classification  spillage.  As  such,  the 
experiment  only  connected  SIPRNET  to  4G  LTE  during  Phase  II  in  light  of  hardware  and 
time  constraints.  NIPRNET  on  the  ship’s  network  accomplished  via  wired  connection. 
The  primary  finding  in  this  phase  was  that  routers  or  other  intermediate  equipment  on  the 
shore-side  might  have  been  misconfigured  because  the  system  had  slower  speeds  than 
originally  anticipated.  The  findings  indicated  that  the  overall  throughput  was  only  about 
twice  as  fast  as  the  traditional  SHF  system.  The  throughput  of  03b  integrated  with 
SIPRNET  was  not  able  to  be  measured  directly  due  to  bit-rate  measuring  applications 
being  unavailable  on  the  classified  network.  With  this  being  the  case,  the  experiment 
team  sent  a  file  of  a  prescribed  length  to  the  shore  side  and  measured  the  length  of  time 
for  completion  to  get  a  rough  estimate. 
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Figure  13.  Pandarra  Net  Configuration  in  Phase  II.  Source:  United  States 

Seventh  Fleet  (2016). 


5.  Pandarra  Net  Design  and  Implementation  Challenges 

The  case  for  computer  simulation  as  a  supplement  to  real  world  C4I  experiments 
can  be  made  based  on  the  policy  and  technical  challenges  faced  during  the  Pandarra  Net 
experiment.  DON  IT  governing  policy  and  administrative  issues  are  not  a  primary  theme 
of  this  thesis,  but  it  is  important  to  note  that  these  can  influence  real-world  experiment 
objectives  and  outcomes.  One  method  to  overcome  these  hurdles  is  to  rely  more  heavily 
on  simulation  before  conducting  exercises.  The  parameters  of  equipment  and  devices 
selected  for  Pandarra  Net  can  be  modeled  into  commercially  available  simulation 
software  tools,  described  later  in  this  chapter.  Once  a  basic  model  is  developed,  it  can  be 
adjusted  and  reused  accordingly.  An  underlying  notion  of  this  thesis  is  that  innovative 
C4I  experiments  should  be  modeled  in  simulation  software  before  Fleet  experimentation 
to  compare  and  contrast  with  real  world  performance. 

The  research  design  of  this  thesis,  in  part,  models  different  simulation 
experiments  based  on  the  observed  equipment  capabilities  and  performance  of  the  LCS  as 
a  wireless  node  during  Pandarra  Net  2015.  Additionally,  a  recommendation  for  network 
management  software  can  be  made  based  on  the  data  gathered  from  these  experiments. 
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D.  QUALNET 

1.  Overview 

QualNet  was  designed  and  is  regularly  updated  by  the  company  Scalable 
Networks.  It  is  a  flexible  software  application  that  can  model  wireless  and  wired  network 
nodes.  The  primary  advantage  of  this  software  is  its  compatibility  with  other  simulation 
programs,  allowing  it  to  be  the  driving  engine  behind  the  operation  of  protocols  and 
applications  within  the  7  OSI  Layers.  Alternatively,  Systems  Tool  Kit  (STK)  software 
simulates  the  physical  positioning  of  nodes  as  they  move  about  between  predetermined 
points  on  a  plot  in  San  Francisco  Bay.  Layer  4  (Transport)  and  lower  will  be  the  layers 
examined  for  the  purpose  of  this  research.  The  data  packets  used  in  the  simulation  will  be 
injected,  using  size  and  characteristics  of  those  observed  from  previous  field  experiments. 

An  advanced  version  of  QualNet,  EXata,  allows  users  to  emulate  networks.  This 
functionality  allows  real-world  network  nodes  to  interact  with  a  simulated  network.  Also, 
network  management  applications  can  interface  with  a  simulated  network  via  plug-ins. 

The  software  version  used  to  simulate  the  network  is  QualNet  7.3  and  contains 
device  libraries  obtained  through  an  educational  license  between  the  researchers  and 
Naval  Postgraduate  School  Information  Sciences  Department.  The  libraries  define 
parameters  for  frequencies,  protocols,  and  packet  routing  information  for  wireless  and 
wired  equipment  to  be  used  in  the  experiment.  The  educational  license  models  utilized 
for  this  thesis  are  the  wireless  and  developer’s  library.  While  this  non-commercial  license 
provided  the  necessary  libraries  to  conduct  the  experiment,  it  limited  the  number  of  nodes 
to  50  that  could  be  simultaneously  simulated.  While  building  the  scenarios,  the  limited 
number  of  nodes  did  not  place  any  additional  constraints  on  the  experiment. 

2.  LTE  Library 

The  Long-Term  Evolution  (LTE)  library,  purchased  to  supplement 

experimentation  involving  MANET,  was  used  to  expand  the  data  collection  of 

simulations  in  QualNet  and  STK.  In  QualNet,  the  LTE  library  provides  an  accurate 

simulation  of  4G  cellular  networks,  based  on  the  3GPP  release  9  standards.  The  software 

consists  of  three  models.  The  PHY  model,  Layer  2  model,  and  Evolved  Packet  Core 
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(EPC)  model.  First,  the  LTE  PHY  models  are  based  on  the  3GPP  36.3XX  architecture, 
which  specifies  Evolved  Universal  Terrestrial  Radio  Access  (E-UTRAN),  physical 
models.  The  main  functions  of  this  model  follow. 

•  Downlink  transmission/reception  using  OFDMA 

•  Uplink  transmission/reception  using  SC-FDMA 

•  Coding/decoding,  modulation/demodulation 

•  Multi-antenna  operation  (MIMO) 

•  CQI/RI/PMI  reporting 

•  Power  control 

•  Cell  selection 

•  Random  access 

•  Measurements  (Scalable  Network  Technologies,  2014c) 

Next  is  the  Layer  2  model,  which  is  also  based  on  the  3GPP  36.3XX  architecture  that 
specifies  E-UTRAN  MAC  and  higher  layer  models.  The  Layer  2  model  consists  of 
following  three  sub-layers. 

•  Packet  Data  Convergence  Protocol  (PDCP):  Handles  ciphering,  header 
compression  and  packet  forwarding  upon  handover. 

•  Radio  Link  Control  (RLC):  AM  data  transfer,  concatenation,  segmentation 
and  reassembly,  re- segmentation  and  reordering  of  data  PDUs. 

•  Media  Access  Control  (MAC):  Multiplexing/demultiplexing  of  SDUs 
into/from  transport  blocks,  radio  resource  scheduling,  and  buffer  status 
report. 

Additionally,  this  layer  includes  the  Radio  Resource  Control  (RRC)  that  is 
responsible  for  connection  management,  handover  control  and  measurement  control 
(Scalable  Network  Technologies,  2014c). 

The  final  layer  in  the  LTE  model  library  is  the  LTE  Evolved  Core  Packet  (EPC), 
Model.  The  EPC  model  is  based  on  the  3GPP  36.423  and  3GPP  36.413  architecture 
which  specifies  X2  Application  Protocol  (X2AP)  and  SI  Application  Part  (S1AP).  In  the 


33 


LTE  library,  EPC  is  a  framework  for  providing  converged  voice  and  date  on  a  4G  LTE 
network.  The  primary  functions  of  the  EPC  are: 

•  Handover  decision 

•  Admission  control 

•  Management  downlink  data  path 

•  X2AP:  Messages  exchanged  on  the  X2  interface 

•  S1AP:  Messages  exchanged  on  the  SI  interface  (Scalable  Network 

Technologies,  2014d) 

The  use  of  the  QualNet  LTE  Model  Library  will  further  enhance  the  four  scenarios 
created  to  test  the  LCS  as  a  major  node  and  is  a  valuable  addition  to  the  research  in  this 
thesis. 

Scenarios,  (i.e.,  network  topologies),  are  created  by  using  a  Graphical  User 
Interface  (GUI)  or  Command  Line  Interface  (CLI)  for  node  placement  and  general 
parameters  are  used  throughout  each  scenario.  The  architecture  of  QualNet  and  its 
interfaces  are  shown  in  Figure  14. 


Figure  14.  QualNet  Architecture.  Source:  Scalable  Network 

Technologies  (2014f). 
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3.  QualNet  Statistics 

Upon  completion  of  a  simulation  run,  QualNet  generates  a  statistics  file  based  on 
the  7-layer  OSI  model  configuration  for  nodes  and  applications  run  between  them.  The 
data  collected  in  this  report  is  in  an  aggregate  format,  displaying  packets  sent,  received, 
or  lost  over  the  total  run  time  of  a  simulation.  The  statistics  and  descriptions  primarily 
used  for  determining  the  effectiveness  of  an  LCS  as  a  major  node  are  illustrated  in 
Table  4.  The  statistics  file  can  be  displayed  in  the  STK/QualNet  GUI,  allowing  the  option 
of  toggling  unwanted  statistical  data  on  or  off.  Also,  the  .stat  file  can  be  imported  to  a 
Microsoft  Excel  Workbook.  The  Excel  Workbook  displays  all  data  in  raw  format, 
including  null  values  of  statistics  not  collected.  Additional  useful  statistics  are  listed  in 
Appendix  C. 


Table  4.  QualNet  Statistics  and  Descriptions.  Source:  Scalable  Network 

Technologies  (2014f). 


Model/Layer 

Statistic 

Description 

Satellite-RSV  PHY 

Signals  transmitted 

Number  of  signals 

transmitted  by  this  physical 

layer  process. 

Satellite-RSV  PHY 

Signals  received  and 

forwarded  to  MAC 

Number  of  signals  received 

by  this  physical  layer 

process  and  subsequently 

forwarded  to  the  MAC 

layer  for  further 

processing. 

Satellite-RSV  PHY 

Signals  locked  on  by 

PHY 

Number  of  signals  that 

triggered  logic  to  lock  the 

transceiver  onto  an 

incoming  signal. 
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Model/Layer 

Statistic 

Description 

Satellite-RSV  PHY 

Signals  received  but 

with  errors 

Number  of  signals  received 

that  were  successfully 

received  by  the  MAC  but 

had  errors  due  to 

interference  or  noise 

corruption. 

Satellite-RSV  PHY 

Average  Eb/No  (dB) 

Average  EB/No  of  the 

channel 

Satellite-RSV  MAC 

UNICAST  packets 

sent  to  the  channel 

Number  of  unicast  packets 

sent  to  the  channel 

Satellite-RSV  MAC 

BROADCAST 

packets  sent  to  the 

channel 

Number  of  broadcast 

packets  sent  to  the  channel 

Satellite-RSV  MAC 

UNICAST  packets 

received  from  channel 

Number  of  unicast  packets 

received  from  the  channel 

Satellite-RSV  MAC 

BROADCAST 

packets  received  from 

channel 

Number  of  broadcast 

packets  received  from  the 

channel 

802.11  a/g  PHY 

Signals  transmitted 

(signals) 

Number  of  signals 

transmitted 

802.11  a/g  PHY 

Signals  detected 

(signals) 

Number  of  signals  detected 

by  PHY 

802.11  a/g  PHY 

Average  path  loss 

(dB) 

Average  path  loss 

LTE  PHY 

Signals  transmitted  by 

the  node. 

Total  number  of  signals 

transmitted 
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Model/Layer 

Statistic 

Description 

LTE  PHY 

Transport  blocks 

received  and 

forwarded  to  MAC 

Total  number  of  transport 

blocks  received  and 

forwarded  to  MAC  for  the 

node. 

802.11  MAC 

Packets  from  network 

Total  number  of  packets 

received  from  the  network 

layer. 

802.11  MAC 

Unicast  packets  sent  to 

channel 

Total  number  of  unicast 

packets  send  to  the  channel 

802.11  MAC 

Broadcast  packets  sent 

to  channel 

Total  number  of  broadcast 

packets  send  to  the  channel 

802.11  MAC 

Unicast  packets 

received  clearly 

Total  number  of  unicast 

packets  received  form  the 

channel 

802.11  MAC 

Broadcast  packets 

received  clearly 

Total  number  of  broadcast 

packets  received  from  the 

channel 

802.11  MAC 

Unicasts  sent 

Total  number  of  successful 

unicast  packets  sent  to  the 

channel 

802.11  MAC 

Broadcasts  sent 

Total  number  of  successful 

broadcast  packets  sent  to 

the  channel 

802.11  MAC 

Unicasts  received 

Total  number  of  successful 

unicast  packets  received 

from  the  channel 
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Model/Layer 

Statistic 

Description 

802.11  MAC 

Broadcasts  received 

Total  number  of  successful 

broadcast  packets  received 

from  the  channel 

LTE  MAC 

Number  of  packets 

from  Upper  Layer. 

The  number  of  PDCP 

SDUs  received  from  the 

upper  layer 

LTE  MAC 

Number  of  packets 

from  Upper  Layer  but 

discard 

The  number  of  PDCP 

SDUs  received  from  the 

upper  layer,  but  can  be 

discarded  for  the  following 

reasons:  Not  connected. 

Broadcast  packet  (not 

supported). 

LTE  MAC 

Number  of  packets  to 

Lower  Layer 

The  number  of  PDCP 

PDUs  transmitted  to  the 

lower  layer 

LTE  MAC 

Number  of  packets 

from  Lower  Layer 

The  number  of  PDCP 

PDUs  received  from  the 

lower  layer 

LTE  MAC 

Number  of  packets  to 

Upper  Layer 

The  number  of  PDCP 

PDUs  transmitted  to  the 

upper  layer. 

AODV  Network 

Number  of  Data 

packets  sent  as  Source 

Number  of  data  packets 

sent  as  the  source  of  the 

data 

AODV  Network 

Number  of  Data 

Number  of  data  packets 
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Model/Layer 

Statistic 

Description 

Packets  Forwarded 

forwarded 

AODV  Network 

Number  of  Data 

Packets  Received 

Number  of  data  packets 

received  as  the  destination 

of  the  data 

AODV  Network 

Number  of  Data 

Packets  Dropped  for 

no  route 

Number  of  data  packets 

dropped  due  to  lack  of 

route. 

LTE  Network 

Number  of  handover 

request  sent 

The  number  of  Handover 

Requests  sent.  This  statistic 

is  collected  only  for  eNB 

nodes 

LTE  Network 

Number  of  handover 

request  received 

The  number  of  Handover 

Requests  received.  This 

statistic  is  collected  only 

for  eNB  nodes 

LTE  Network 

Number  of  handover 

request 

acknowledgment  sent 

The  number  of  Handover 

Requests  Ack  sent.  This 

statistic  is  collected  only 

for  eNB  nodes 

LTE  Network 

Number  of  handover 

request 

acknowledgment 

received 

The  number  of  Handover 

Requests  Ack  received. 

This  statistic  is  collected 

only  for  eNB  nodes 

OLSR  Application 

Hello  Messages 

Received 

Total  number  of  Hello 

Messages  Received  by  the 

node 
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Model/Layer 

Statistic 

Description 

OLSR  Application 

Hello  Messages  Sent 

Total  number  of  Hello 

Messages  Sent  by  the  node 

CBR  Application 

First  Unicast 

Fragment  Sent 

(seconds) 

Time  in  seconds,  when 

first  unicast  fragment  was 

sent 

CBR  Application 

Last  Unicast  Fragment 

Sent  (seconds 

Time  in  seconds,  when  last 

unicast  fragment  was  sent 

CBR  Application 

Total  Unicast 

Fragments  Sent 

(fragments) 

Total  number  of  unicast 

fragments  sent 

CBR  Application 

First  Unicast  Message 

Received  (seconds) 

Time  in  seconds,  when 

first  unicast  message  was 

received 

CBR  Application 

Last  Unicast  Message 

Received  (seconds) 

Time  in  seconds,  when  last 

unicast  message  was 

received 

CBR  Application 

Total  Unicast 

Messages  Received 

(messages) 

Total  number  of  unicast 

messages  received 

CBR  Application 

Unicast  Received 

Throughput 

(bits/second) 

Unicast  throughput  at  the 

server  (bits/second) 
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4.  QualNet  Application  Layer  Models 

QualNet  7.3’ s  simulated  applications  consist  of  models  that  can  be  added  to  nodes 
and  customized  with  parameters  that  can  be  tailored  to  observe  various  aspects  of 
network  performance.  The  majority  of  applications  allow  the  user  to  set  the  application 
start  time,  stop  time,  the  size  of  data  bytes,  and  the  interval  between  transmitting  items. 
The  applications  oriented  toward  the  research  on  an  LCS  performing  as  a  major  node  are 
listed  in  this  section;  additional  applications  are  listed  under  Appendix  A. 

5.  Constant  Bit  Rate  (CBR) 

The  Constant  Bit  Rate  (CBR)  traffic  generator  creates  items,  or  UDP  segments, 
and  transmits  them  at  a  steady  rate  within  a  set  interval.  The  application  can  be 
configured  to  start  or  end  at  any  time  during  a  scenario.  The  CBR  item  size  can  be 
adjusted  within  QualNet  defined  upper  and  lower  limits  but  is  not  necessarily  meant  to 
stress  or  test  the  limits  of  a  network.  In  most  experiments,  it  is  useful  for  adding 
background  traffic  while  testing  other  applications.  In  MANET  and  WMN  settings,  it  is 
useful  for  testing  routes,  as  unicast  packets  sent  and  received  can  be  used  as  a  metric  for 
determining  availability  through  UDP  at  the  Transport  Layer.  Also,  unicast  throughput  is 
measured  in  bits/second  (Scalable  Network  Technologies,  2014e). 

6.  File  Transfer  Protocol/Generic  (FTP) 

The  File  Transfer  Protocol  (FTP)  Generic  is  a  traffic  generator  useful  for 
simulating  the  exchange  of  established  file  sizes  between  a  client  and  server.  The  number 
of  files  sent  is  set  to  a  maximum  number  over  a  user-defined  period.  The  application  will 
terminate  at  the  end  of  the  prescribed  length  even  if  all  files  are  not  successfully 
transferred.  If  desired,  the  start  and  end  time  can  be  set  to  a  value  that  will  allow  the  FTP 
application  to  run  throughout  the  entirety  of  a  simulation,  terminating  when  all  files  are 
sent.  This  application  is  capable  of  measuring  unicast  throughput  from  the  client  to  the 
server  like  the  CBR  application,  but  using  TCP/IP  at  the  Transport  Layer  instead  of  UDP. 
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7. 


Super  Application  Traffic  Generator 


The  Super  Application  Traffic  Generator  is  capable  of  modeling  different 
multimedia  formats  based  on  user  input.  The  supported  encoding  schemes  are  listed  in 
Table  5. 


Table  5.  Super  Application  Encoding  Schemes.  Source: 
Scalable  Network  Technologies  (2014f). 


Codec 

Default  Packet  Size  (Bytes) 

Default  Packet  Interval  (ms) 

H.261 

160 

20 

H.263 

160 

20 

MPEG1.M 

2500 

20 

MPEG1.H 

7500 

20 

MPEG2.M 

12500 

20 

MPEG2.H 

37500 

20 

G.711 

160 

20 

G.729 

20 

20 

G.723.1ar6.3 

23 

30 

G.726ar32 

80 

20 

G.726ar24 

60 

20 

G.728arl6 

40 

30 

CELP 

18 

30 

MELP 

8 

22.5 
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This  traffic  generator  is  useful  for  testing  the  limits  of  a  network’s  performance  and  is 
well-suited  for  simulating  some  of  the  applications  that  would  be  used  in  a  real-world 
environment  with  the  LCS  performing  as  a  major  node. 

E.  EXATA 

EXata  is  a  network  emulation  program  which  has  a  GUI  layout  nearly  identical  to 
QualNet’s.  EXata  differs  from  QualNet  in  its  capabilities  and  features,  including  its 
enhanced  capability  to  create  an  emulated  network  testbed  on  a  server  or  workstation.  For 
the  purpose  of  experiment  design,  it  will  be  used  to  enhance  STK/QualNet  scenarios  built 
around  the  LCS  and  associated  nodes  through  a  proof-of-concept  experiment  proposal 
demonstrating  the  capability  to  interconnect  network  management  software  (NMS)  with 
an  emulated  LCS  node.  EXata  uses  a  Connection  Manager  Application,  separate  from  the 
EXata  application  itself,  to  connect  real-world  devices  to  its  emulated  network.  The 
devices  connected  to  the  network  as  emulated  nodes  can  run  a  NMS  or  any  other  installed 
third-party  application  to  inject  network  metrics  into  the  testbed.  The  model  libraries  for 
nodes  and  interfaces  in  EXata,  similar  to  QualNet,  are  comprised  of  devices  that 
represent  the  following  network  elements  according  to  the  EXata  5.3  User’s  Guide: 

•  Routers 

•  Switches 

•  Access  points 

•  Ground  stations 

•  Satellites 

•  Cell  phones 

•  Radios 

•  Sensors 

•  PCs 

•  Servers 

•  Firewalls 


43 


•  Other  security  apparatus 

•  Communications  links  that  interconnect  the  nodes  (Scalable  Network 
Technollgies,  2014a) 

EXata  can  also  be  used  for  network  design  and  architecture  optimization,  capacity 
prediction,  RF  interference  and  propagation  modeling,  mission  planning,  hardware  and 
software  development,  communications  problem  identification  and  equipment  scalability 
evaluation  (Scalable  Network  Technologies,  2014a).  Using  this  program  will  mimic  the 
functionality  of  a  real  network,  and  provides  a  “high-quality  reproduction  of  external 
behavior  so  that  the  emulation  is  indistinguishable  from  the  actual  system”  (Scalable 
Network  Technologies,  2014a).  The  use  of  emulation  provides  an  environment  which 
quickly  shows  the  impact  of  design  decisions,  and  how  applications  will  perform  in  the 
real  world  (Scalable  Network  Technologies,  2014a). 

Simple  Network  Management  Protocol  (SNMP)  capability  is  an  additional  feature 
EXata  provides  which  QualNet  does  not.  The  software  can  enable  the  addition  of  SNMP 
agents  and  the  upload  of  SNMP  configuration  files  on  both  simulated  and  emulated 
nodes.  The  SNMP  functionality  enables  NMS,  such  as  SolarWinds,  the  ability  to  detect 
these  nodes  and  add  them  to  a  Manager  Database  (MDB). 

EXata  offers  many  benefits  over  QualNet.  However,  Scalable  Networks  does  not 
offer  an  educational  license  version  of  it.  Research  using  EXata  was  limited  in  scope  to 
what  could  be  accomplished  with  a  two-week  trial  version  provided  by  the  company. 

A  screenshot  of  EXata  is  displayed  in  Figure  15. 
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Figure  15.  EXata  Screenshot.  Source:  Scalable  Network 

Technologies  (2014b). 


Other  key  program  features  and  capabilities  follow: 

•  Develop  simulation  models  for  network  technologies. 

•  Develop  communications  protocol  models  using  the  OSI-style  architecture 
of  the  EXata  protocol  stack. 

•  Develop  wireless  networks  of  real-world  size. 

•  Perform  what-if  analyses:  Analyze  the  performance  of  networks  and 
perform  ‘what-if  analyses  to  optimize  them. 
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•  Connect  real  networks,  applications,  and  devices  with  EXata  emulated 
network. 

•  Manage  an  emulated  network  with  the  SNMP  agent,  which  enables  the  use 
of  standard  SNMP  managers  to  view,  monitor  and  control  emulated 
networks.  (Scalable  Network  Technologies,  2014a,  p.  2-4) 

Scenarios  can  be  built  from  scratch  or  from  the  libraries  in  EXata  which  contain  a  variety 
of  real-world  and  network  components.  EXata  comes  with  a  default  set  of  libraries, 
including  the  Network  Management,  Wireless,  Cellular  and  LTE  libraries  that  were  used 
in  the  four  scenarios  designed  for  this  thesis  (Scalable  Network  Technologies,  2014a). 

Due  to  restrictions  on  the  Naval  Postgraduate  School  network,  EXata  will  not  be 
used  for  this  research  but  should  be  considered  for  future  work. 

F.  SYSTEMS  TOOL  KIT 

Systems  Tool  Kit  (STK)  is  a  modeling  software  developed  and  periodically 
updated  by  Analytical  Graphics  Incorporated  (AGI).  The  software’s  primary  use  is  for 
the  modeling  of  communication  satellite  performance  with  ground  stations,  but  it  has 
since  grown  into  a  robust  palette  capable  of  modeling  communications  between  a 
combination  of  ground,  air,  sea  and  space  communication  nodes.  STK  11.1,  the  most 
current  version  at  the  time  of  this  study,  allows  a  user  to  interface  many  software 
applications  with  STK,  including  unlicensed  third-party  programs.  The  robust  capabilities 
of  the  software  suite  create  opportunities  for  integrating  network  management  software 
overlays.  Also,  STK’s  output  feeds  into  servers  that  can  translate  XML,  such  as  the 
CENETIX  SA  Server.  This  capability  allows  for  the  merging  of  actual  network  nodes 
used  in  field  experimentation  with  simulated  network  nodes. 

STK  uses  object-oriented  software  to  enable  a  user  to  place  objects,  in  the  form  of 
locations  or  vehicles,  on  a  geodetic  representation  of  the  Earth.  Models  are  viewed  as 
scalar  representations  in  either  two-dimensions  (2D)  or  three-dimensions  (3D).  Objects 
can  also  be  placed  on  other  objects,  such  as  antenna  objects  on  a  ship  object,  tying  the 
positional  characteristics  of  antenna  objects  to  their  hosting  platforms.  For  example,  if  a 
mobile  parent  object  moves  throughout  the  simulation,  the  child  object  attached  to  it  is 
carried  with  and  is  affected  by  the  same  weather  conditions,  terrain  or  signal  reception. 
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STK  has  a  database  of  ship  and  vehicle  models  that  can  be  downloaded  to  a 
software  library  for  inclusion  in  scenarios.  The  online  database  contains  models  of  both 
the  Freedom  and  Independence  class  variants  of  the  LCS,  as  well  as  other  manned  and 
unmanned  U.S.  Navy  platforms.  The  extensive  library  of  military  platforms  available  for 
simulation  enables  testing  a  broad  range  of  routing  protocols  and  data  rates. 

A  primary  reason  for  choosing  STK  is  its  compatibility  with  QualNet,  which 
allows  for  a  more  in-depth  analysis  of  nodal  performance  between  the  LCS  and 
connected  assets.  The  interaction  between  QualNet  and  STK  is  shown  in  Figure  16. 


Figure  16.  QualNet/STK  Interaction.  Source:  Scalable  Network 

Technologies  (2014f). 
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G.  CENETIX  TACTICAL  NETWORK  TESTBED 
1.  Tactical  Networking  Testbed  (TNT) 

The  purpose  of  integrating  data  from  previous  experiments  in  the  TNT  is  to 
determine  the  effectiveness  of  the  Littoral  Combat  Ship  (LCS)  platform  as  a  major  node 
with  interconnected  vessels,  both  manned  and  unmanned,  that  would  perform  operations 
in  the  littorals.  Simulated  network  configurations  are  used  to  obtain  data  on  performance 
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at  the  optimal  bandwidth  levels.  Navy  ships  rely  heavily  on  satellite  communications, 
which  will  be  utilized  in  modeled  networking  configurations  to  provide  off-ship 
communications  in  addition  to  the  more  flexible  mesh  networks  used  by  the  LCS  and 
other  vessels  that  make  up  the  simulated  testbed  environment.  In  this  thesis,  the 
feasibility  of  using  a  current  LCS  architecture  and  platform  as  an  Internet  gateway  for 
multiple  vessels  will  be  examined  as  a  possibility  of  particular  interest  use  during 
operations  in  the  littorals.  While  there  will  be  multiple  benefits  to  the  proposed 
configuration,  the  main  advantage  is  improved  and  uninterrupted  command  and  control 
of  multiple  vessels.  Simulations  of  these  settings  will  be  based  on  the  tactical  networking 
testbed  (TNT)  environment.  The  TNT  has  several  benefits  including  the  integration  of 
people,  networks,  sensors  and  unmanned  systems  and  also  the  ability  to  incorporate  plug- 
and-play,  tactical  and  unmanned  systems  networking  capabilities  with  global  reach  back 
(Bordetsky  &  Netzer,  2010).  The  simulated  scenarios  in  this  thesis  will  take  advantage  of 
the  San  Francisco  Bay  environment  to  include  manned  and  unmanned  vessels  and  several 
land-based  sensors.  While  the  configurations  may  vary,  the  TNT  environment  can  be 
configured  for  a  wide  variety  of  scenarios,  and  a  typical  test  configuration  will  include 
data  exchange  in  the  forms  of  video,  audio  and  text  files.  During  these  tests,  the  primary 
metrics  will  focus  on  network  performance  with  moving  nodes  and  determining  whether 
or  not  the  wireless  mesh  network  is  properly  healing  itself  should  a  node  drop  offline. 
The  main  goal  is  to  determine  the  effectiveness  of  the  LCS  as  a  major  node  with  a  variety 
of  network  configurations,  utilizing  the  capability  and  flexibility  of  the  platform  to  test 
available  communications  paths  in  a  wireless  mesh  network  configuration.  There  are 
tremendous  tactical  and  operational  advantages  to  always  being  connected.  Using 
previous  experimentation  in  the  TNT  as  a  stepping  stone  to  test  traditional  and  novel 
communication  configurations  is  one  of  the  major  drivers  of  this  research.  The  work  in 
this  thesis  will  primarily  focus  on  the  maritime  portion  of  the  TNT,  particularly  maritime 
interdiction  operations  (MIO).  The  following  network  diagram  (Figure  17)  is  an  example 
of  a  configuration  that  will  be  simulated  in  the  research  (Bordetsky  &  Netzer,  2010). 
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Figure  17.  Sample  MIO  Network  Diagram.  Source:  International  C2 

Journal  (2010). 


The  TNT  also  allows  for  the  monitoring  of  network  performance,  the 
identification  of  downed  nodes  and  notification  of  new  nodes  in  the  network.  Accessing 
the  TNT  can  be  accomplished  by  the  following  methods. 

•  Combining  sensors  and  mesh  networking  elements  in  the  closed  IP  space 
of  the  TNT  testbed  with  fixed  IPv4  or  IPv6  addresses 

•  Connection  via  remote  local  area  network  (LAN),  including  command  or 
operations  centers  through  VPN 

•  Sensor  and  unmanned  vessel/vehicle  integration  via  the  application  layer 
interoperability  interface 

•  Access  via  a  collaborative  portal  or  peer-to-peer  collaborative  clients  and 
VTC  (Bordetsky  &  Netzer,  2010) 


49 


Nodes  equipped  with  Wave  Relay  devices  use  Orthogonal  Frequency  Division 
Multiplexing  (OFDM)  for  participation  in  the  WMN  or  MANET.  In  Ka  Ki  Yeung’s 
thesis,  Detailed  OFDM  Modeling  in  Network  Simulation  of  Mobile  Ad  Hoc  Networks,  he 
explains  that  one  benefit  of  OFDM  is  that  it  converts  a  wideband  signal  into  a  series  of 
independent  narrowband  signals  and  places  them  side-by-side  in  the  frequency  spectrum. 
Using  OFDM  is  also  beneficial  since  the  subcarriers  in  a  particular  frequency  band  can 
overlap  (Yueng,  2003).  Used  on  the  physical  layer,  OFDM  is  an  encoding  technology  for 
transmitting  signals  via  RF  (Abdullah,  Ahmed,  &  Mandal,  2012).  Additionally,  OFDM 
eliminates  the  problem  of  multipath  propagation  due  to  its  low  date  rate  per  subcarrier, 
which  is  a  fraction  of  a  conventional  single  carrier  system  with  similar  throughput  and  is 
a  major  advantage  of  OFDM  modulation  (Yeung,  2003).  Other  studies  showed  the  use  of 
adaptive  OFDM  in  ad  hoc  networks  improves  the  energy  performance  of  mobile  nodes. 
The  performance  gains  were  noted  when  adaptive  OFDM  was  used  on  the  physical  layer 
(Abdullah  et  al.,  2012). 

These  means  of  access  allow  for  a  variety  of  monitoring  to  not  only  view  video 
feeds  but  network  performance  as  well.  The  TNT  remains  a  solid  platform  that  will  be 
used  to  determine  the  optimal  configuration  for  wireless  mesh  networks  with  littoral 
combat  ships  serving  as  the  primary  Internet  gateways. 

2.  San  Francisco  Fleet  Week 

Fleet  Week  is  an  annual  event  that  occurs  in  San  Francisco  Bay  during  the  month 
of  October.  Since  its  inception  in  1981,  select  U.S.  and  foreign  naval  vessels  arrive  to 
participate  in  maneuvers  at  sea  in  the  surrounding  waters  with  a  follow-on  public  affair 
gathering  ashore  (Zamora,  2014).  In  recent  years  various  LCS  hull  numbers  have  taken 
part  in  this  event.  This  point  is  notable  because,  with  proper  coordination  between  NPS 
research  associates  and  LCS  program  stakeholders,  a  visiting  LCS  may  be  involved  in  a 
CENETIX  TNT  experiment  to  gather  real  world  data  on  the  vessel’s  performance  as  a 
major  node.  A  CODA-Lite  system  as  well  as  fly-away  kits,  similar  to  what  was  used 
during  the  Trident  Warrior  experiment,  could  provide  valuable  data  if  installed  on  Fleet 
Week  vessels  and  interfaced  with  the  TNT. 
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The  design  for  the  STK  simulation  is  based  on  such  a  theoretical  real  world 
experiment.  The  vessels  and  platforms  chosen  to  interface  with  the  LCS  as  a  major  node 
in  the  simulation  are  those  that,  wherever  possible,  would  normally  participate  in  Fleet 
Week  in  addition  to  platforms  that  have  been  used  in  past  TNT  experiments. 

H.  UNMANNED  VESSELS  AND  TACTICAL  CONTROL  DATALINK 

(TCDL) 

To  expand  the  WMN/MANET  beyond  the  LCS  and  traditional  manned  ships  or 
aircraft,  unmanned  vessels  are  employed  to  serve  as  additional  network  nodes.  The  two 
platforms  utilized  in  the  simulations  are  the  RQ-8  Fire  Scout  unmanned  aerial  vehicle, 
and  the  Seafox,  an  unmanned  surface  vessel.  In  real-world  situations,  either  can  be 
equipped  with  the  network  equipment  required  to  operate  in  an  existing  WMN  or 
MANET.  With  the  addition  of  the  Tactical  Control  Datalink,  either  platform  can  relay 
various  types  of  data  back  to  an  afloat  operations  center,  which  in  simulations  is  the  LCS. 

The  Navy’s  RQ/MQ-8B  Fire  Scout  is  the  first  unmanned  vehicle  of  its  kind  and 
possesses  the  ability  to  perform  vertical  takeoffs  and  landings  on  any  aviation-capable 
ship.  It  can  also  monitor  targets  up  to  150  nautical  miles  out  and  report  time-critical  data 
(Cubic,  2013).  Additional  capabilities,  to  include  communications  relay  capability,  make 
the  Fire  Scout  a  platform  that  can  easily  be  integrated  into  an  existing  MANET  (Cubic, 
2013). 

The  Seafox  is  an  unmanned  surface  vessel,  built  on  a  17-foot,  aluminum  rigid  hull 
inflatable  boat  (RHIB)  platform.  In  the  current  configuration,  they  deploy  with 
communications  hardware  allowing  for  remote  control  and  wireless  networking 
capabilities  (Naval  Postgraduate  School,  n.d.b.). 

Utilizing  a  TCDL,  either  platform  is  capable  of  not  only  communicating  with  an 
LCS  or  land-based  operating  center  but  also  imagery  collection,  intelligence  gathering, 
and  precision  targeting.  Detailed  specifications  for  TCDL  are  shown  in  Figure  18. 
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Figure  18.  TCDL  Terminal  Specifications.  Source:  Cubic  (2013). 


AIR  DATA  TERMINAL  (ADT) 

Key  Features 

■  Ku-band  CDL  transceiver 

■  200  kbps  to  44.73  Mbps 

■  CDL  specification  7681990-compliance 

■  Internal  encryption 

■  Omnidirectional  and  directional  antennas 

■  Ethernet,  serial,  and  analog  Interfaces  (commercial  standard, 
nonproprietary) 

■  Integrated  video  encoding  (MPEG-2) 

■  Tested  Interoperable  with  CDL  terminals  from  other  vendors 


GROUND  DATA  TERMINAL  (GDT) 

Key  Features 

■  Ku-band  CDL  transceiver 

■  200  kbps  to  44.73  Mbps 

■  CDL  specification  7681990-compliance 

■  Internal  encryption 

■  Omnidirectional  and  directional  antennas 

■  Ethernet,  serial,  and  analog  interfaces 
(commercial  standard,  nonproprietary) 

■  Video  decoding  (MPEG-2) 

■  Interoperable  with  CDL  Terminals  from  all  vendors 


Performance  Characteristics  ■  Optional  ruggedized  laptop  display  with  control  software 


•  Frequency 

Ku-band  (transmit  &  receive) 

Performance  Characteristics 

•  Data  rate 

200  kbps -44.73  Mbps 

•  Frequency 

Ku-band  (transmit  &  receive) 

•  Transmit  RF  power 

10  Watts 

•  Data  Rate 

200  kbps -44.73  Mbps 

•  Operations  mode 

Full-duplex 

•  Transmit  Power 

10  Watts 

•  Interfaces 

RS-170  analog  video 

•  Antenna  Gain 

39.6  dBi  (directional). 

(input  to  ADT) 

0  dBi  (omni) 

Ethernet 

•  Operating  Mode 

Full-duplex 

Analog  audio  (input  &  output) 

•  Interfaces 

RS-170  analog  video 

•  Video 

Analog  NTSC 

(output  from  GDT) 

•  Encryption 

Type  1 

Ethernet 

Physical  Characteristics 

Analog  audio  (input  &  output) 

Transceiver 

•  Video 

Analog  NTSC  output 

•  Size 

22.5"  x  14.25"  x  8.5" 

•  Encryption 

Type  1 

•  Weight 

37.8  lbs. 

Physical  Characteristics 

•  Power  Consumption 

260  W  maximum 

•  Primary  Power 

28VDC 

Remote  Antenna 

•  Vibration  &  Shock 

MIL-STD-810F 

•  Size 

60"  high  x  56"  diameter 

•  EMI/EMC 

MIL-STD-461E 

tripod  foot  circle 

•  Temperature 

-40°  C  to +55°  C 

•  Weight 

147  lbs. 

Directional  Antenna 

Modem  Assembly 

•  Size 

8.0"  dia.  x  9"  high 

•  Size 

22.5"  x  23.5"  x  6" 

(excluding  connectors) 

•  Weight 

29.7  lbs. 

•  Weight 

7.0  lbs. 

•  Power  Consumption 

35  W  (supplied  by  power 

•  Power  Consumption 

10  W  maximum 

supply) 

•  Primary  Power 

28VDC 

•  Power 

28VDC 

•  Vibration  &  Shock 

MIL-STD-810F 

•  Vibration  &  Shock 

MIL-STD-810F 

•  EMI/EMC 

MIL-STD-461E 

•  EMI/EMC 

MIL-STD-461E 

•  Temperature 

-40°  C  to +55°  C 

•  Temperature 

-40°  C  to +55°  C 

Omni  Antenna 

•  Weight 

0.33  lbs. 
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III.  RESEARCH  DESIGN 


The  simulation  is  designed  around  concepts  from  the  two  experiments  described 
in  Chapter  II;  Pandarra  Net  and  the  San  Francisco  Bay  MIO/TNT  event.  Naval  platforms 
typically  participating  in  a  Fleet  Week  were  also  utilized  in  the  experiment.  Four 
scenarios  were  designed  to  test  LCS  performance  as  a  major  node.  Individual  scenarios 
were  created  for  the  LCS  to  perform  as  a  gateway,  router,  hub,  and  bridge.  Each  scenario 
used  antennas  and  equipment  identical  or  similar  to  those  used  in  previous  real-world 
experiments.  Three  U.S.  Navy  platforms  were  used  in  two  of  the  four  scenarios;  a 
Freedom  Class  LCS,  a  Ticonderoga  Class  cruiser,  and  an  Arleigh  Burke-class  destroyer. 
Depending  on  the  scenario  type,  smaller  unmanned  and  manned  assets  were  used  in 
addition  to  these  baseline  platforms.  Figure  19  is  a  screen  capture  of  some  of  the  STK  3D 
models  used  in  the  SF  Bay  scenarios. 

Figure  19.  STK  3D  Models  Used  in  the  SF  Bay  Scenario 


In  the  2015  MIO  experiment,  the  Coast  Guard  Station  on  Yerba  Buena  Island 
served  as  a  NOC  and  was  used  as  a  surrogate  LCS  (Maupin,  2016).  Lor  simulation 
purposes,  Yerba  Buena  Island  will  not  be  used  as  a  NOC  or  surrogate  LCS  but  can  act  as 
an  additional  node  as  necessary. 
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A. 


WMN 


The  mesh  network  in  the  simulation  was  comprised  of  antenna  objects  with 
characteristics  as  described  in  Chapter  II.  The  STK  simulation  of  Wave  Relay’s 
directional  antennas  consisted  of  three  rectangular  pattern  antenna  objects  mounted  on 
the  stern  of  equipped  vessels  and  hand-held  isotropic  radios  for  smaller,  manned  assets. 
Persistent  System’s  Wave  Relay  over  Internet  Protocol  (WRoIP),  used  on  radios  and 
devices  in  the  mesh,  is  proprietary  and  not  available  for  modeling  via  STK/QualNet.  Due 
to  this  limitation,  AODV  is  substituted  for  Wave  Relay  as  the  routing  protocol  at  the 
MAC  layer  of  WMN  nodes  in  the  STK/QualNet  simulation.  The  Wave  Relay  nodes  in 
the  mesh,  including  the  antenna  on  the  LCS,  formed  their  own  subnet — this  was  the  first 
autonomous  system  added  to  the  scenario.  In  practice,  ship  ADNS  networks  also  form 
autonomous  systems  when  routed  through  long-haul  RF  paths  back  to  a  shore  NOC  in  the 
same  AOR.  In  the  scenario,  the  LCS  and  connected  nodes  in  the  mesh  formed  an 
autonomous  system  at  the  operational  front  using  the  LCS  as  a  NOC.  Lastly,  the  LCS 
served  as  a  gateway  by  bridging  the  mesh  to  another  autonomous  system,  03b’ s  satellite 
constellation,  and  long-haul  throughput.  The  LCS  performing  as  a  gateway  is  an 
important  aspect  of  the  research  design  due  to  its  tactical  and  QoL  implications.  A  wire 
frame  displaying  the  propagation  of  the  simulated  Wave  Relay  Sector  Antenna  mounted 
on  the  deck  of  the  LCS  is  displayed  in  Figure  20. 


Figure  20.  Wave  Relay  Sector  Antenna  Mounted  on  LCS 
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B.  MANET 

The  MANET  in  the  applicable  scenarios  was  formed  using  4G  LTE  technology. 
The  LCS,  equipped  with  a  ZDA  1.5M  Band  17  antenna  and  LTE  core  server,  created  an 
LTE  bubble  for  data  sharing  among  participating  nodes.  Devices  connected  to  the  bubble 
consisted  of  Samsung  Galaxy  Note  II  devices,  band  4  antennas,  and  LTE  enabled 
cameras  and  imaging  devices.  The  STK/QualNet  interface,  through  a  purchased  QualNet 
license,  is  capable  of  modeling  LTE  elements  in  a  scenario. 

C.  SCENARIO  1:  LCS  PERFORMING  AS  A  GATEWAY 

The  LCS  in  the  simulation  was  equipped  with  two  1.2M  satellite  terminals  as  well 
as  a  Wave  Relay  Sector  Antenna  Array,  containing  three  separate  120-degree  directional 
antennas  within  its  housing  unit.  In  the  simulation,  the  1.2M  satellite  terminals  are 
mounted  on  port  and  starboard  side  of  the  LCS  on  its  upper  level,  and  the  Antenna  Array 
is  physically  fitted  to  the  flight  deck.  Although  this  may  not  have  been  the  best  location 
for  efficient  RF  propagation  paths,  it  is  a  realistic  location  based  on  the  premise  that  the 
device  would  be  set  up  ad-hoc  in  a  real-world  experiment.  The  maritime  Wave  Relay 
antenna  in  the  scenario  can  easily  be  relocated  to  a  mast  yard  arm  or  other  location  if 
needed.  The  physical  mounting  of  attached  antenna  objects  on  models  in  STK  is 
accomplished  using  a  Cartesian  coordinate  system  in  relation  to  the  model.  The  STK 
parameters  of  a  mounted  Wave  Relay  Sector  Antenna  are  displayed  in  Figure  21. 
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Figure  21.  Wave  Relay  Sector  Antenna  Propogation  and  Orientation 
Parameters  onboard  the  LCS.  Source:  Scalable  Network 
Technologies  (2016). 
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The  STK  mounting  parameters  of  the  1.2-meter  KA-band  terminals  are  displayed 
in  Figure  22  and  their  respective  locations  on  the  3D  model  in  Figure  23. 


Figure  22.  03b  Ka-Band  Terminal  Mounting  Parameters.  Source:  Scalable 

Network  Technologies  (2016). 


B  Basic 

Definition 
\-  Location 
Pointing 
SensorAzEI... 
Refraction 
Resolution 
Description 
□  2D  Graphics 
Attributes 
Projection 
Boresight 
L  Display  Tim... 

ra  ftranhirc 


Location  Type:  |  Fixed 
r  Fixed  Location 


Type:  Cartesian 


X:  |0.009  km 

Y: 


-0.006  km 
Z:  |0.019km 


a 


a 


Figure  23.  03b  Ka-Band  Terminals  Mounted  on  Simulated  LCS.  Source: 

Scalable  Network  Technologies  (2016). 
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The  terminals  established  links  with  the  03b  MEO  constellation  over  wireless 
subnets  between  the  ground  stations  and  satellites.  As  illustrated  in  chapter  II,  03b 
maintains  a  constellation  of  12  satellites,  with  an  orbital  period  of  6  hours,  positioned 
above  the  equator.  In  the  simulation,  4  of  these  satellites  were  selected  to  communicate 
with  the  LCS.  The  satellites  use  steerable  beams  to  effectively  cover  regions  +/-  45 
degrees  from  the  equator;  any  area  located  above  or  below  the  45-degree  margin 
experience  major  degradations  in  service.  The  latitude  of  SF  Bay  is  approximately  37.7  N 
and  is  within  a  serviceable  region.  The  LCS  in  the  scenario  relays  communications  off- 
ship  to  the  03b  satellite,  which  in  turn  relays  it  to  an  03b-owned  ground  station  through 
a  bent-pipe  architecture.  The  STK  orbital  parameters  of  an  03b  satellite  are  illustrated  in 
Figure  24. 


Figure  24.  03b  Orbital  Parameters.  Source:  Scalable  Network 

Technologies  (2016). 
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Short  Description: 
Long  Description: 


SSC  Number 

39191 

Common  Name 

03B  M001 

Official  Name 

03B  PFM 

International  Number 

201 3-031 D 

Owner 

03B 

Mission 

Unknown 

Launch  Site 

FRG 

Launch  Date 

20130625 

Launch  Time 

Deorbit  Date 

Launch  Sequence 

Mass 

kg 

Apogee 

8069  km 

Perigee 

8062  km 

Period 

287.9  min 

Inclination 

0.0  deg 

Status 

Active 

In  the  future,  the  Ka-band  transponder  may  be  used  by  03b  satellites  to  be 

reconfigured  to  direct  a  signal  to  government-owned  facilities  such  as  a  Naval  Computer 

Telecommunications  Area  Master  Station  (NCTAMS).  For  simplicity,  and  based  on  data 

from  Pandarra  Net  2015,  the  simulated  scenario  used  03b  earth  stations.  The  company 

currently  owns  two  earth  stations  in  the  United  States:  one  in  Vernon,  Texas  and  the  other 
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in  Haleiwa,  Hawaii.  According  to  a  technical  paper  on  03b’ s  services,  the  Haleiwa  and 
Vernon  earth  stations  have  very  similar  link  budgets  (D’Ambrosio,  2015).  The  simulation 
used  the  Vernon,  Texas  ground  station  as  the  relay  for  Scenario  1.  The  simulation  did  not 
model  the  path  from  the  ground  station  to  the  nearest  NCTAMS  facility.  Figure  25 
displays  the  transmit  gains  and  losses  of  03b  satellites  operating  at  5  degrees  elevation  in 
the  West  as  viewed  from  the  03b  station  in  Vernon,  Texas. 


Figure  25.  03b  Satellite  Transmit  Gains  as  Viewed  from  Vernon,  Texas,  with 

a  Satellite  at  151  Degrees  West.  Source:  03b  Non- Geo  stationary 
Satellite  System  (Barnett,  2013). 
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03b  satellite  receive  gains  from  Vernon,  Texas  are  displayed  in  Figure  26 


Figure  26.  03b  Satellite  Receive  Gains  as  Viewed  from  Vernon,  Texas,  with 

a  Satellite  at  151  Degrees  West.  Source:  03b  Non- Geo  stationary 
Satellite  System  (Barnett,  2013). 
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03b  satellite  gains  from  the  STK  simulation  are  shown  in  Figure  27. 


Figure  27.  03b  Satellite  Gains  from  STK  Simulation  as  Viewed  from  Vernon, 

Texas,  with  a  Satellite  at  151  Degrees  West 


The  Cruiser  and  Destroyer  conducting  operations  with  the  LCS  were  also 
equipped  with  Wave  Relay  Sector  Antenna  Arrays.  The  Wave  Relay  devices  were 
mounted  to  the  flight  decks  of  these  vessels  like  that  of  the  LCS  enabling  the  vessels  to 
send  data  and  connect  through  the  LCS’  IGW. 

The  duration  of  the  scenario  was  six  hours.  The  length  was  selected  based  on  the 
six-hour  orbital  period  of  an  03b  satellite.  In  the  scenario,  the  three  vessels  were  assigned 
screen  sectors  in  the  form  of  approximated  3-by-3  kilometer  (KM)  operational  boxes 
outside  the  mouth  of  San  Francisco  Harbor.  The  LCS  took  a  position  in  the  center 
operational  box  with  the  cruiser  and  destroyer  operating  north  and  south,  respectively. 
The  waypoints  for  each  vessel  are  randomly  chosen  within  each  operational  box. 

The  waypoints  of  the  ship  object  models  were  the  first  items  built  into  the 
simulation.  The  process  for  determining  object  positions  throughout  the  scenario 
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involved  the  use  of  STK’s  smooth  rate  calculations.  The  LCS  and  DDG  transited 
throughout  their  operational  boxes  with  a  speed  of  10  knots,  while  the  CG  transited  at  a 
slightly  slower  speed  of  5  knots.  With  the  smooth  rate  option  selected  in  each  ship’s 
object  window,  STK  automatically  calculated  waypoint  arrival  times  based  on  these 
constant  speed  settings  and  a  variable  distance  covered — this  in  turn  automatically 
calculated  total  scenario  time.  Waypoints  for  each  object  were  randomly  selected  and 
added  until  the  elapsed  scenario  time  had  reached  a  6  hour  period  or  greater.  Once  the 
desired  scenario  time  had  been  reached,  the  STK  analysis  period,  which  collects 
statistics,  was  modified  in  the  scenario  window  to  encompass  1900  on  August  10th  to 
0100  on  August  11th. 

Next,  03b  satellite  objects  were  loaded  into  the  scenario.  The  ephemeris  data  for 
these  objects  was  obtained  from  previous  research  completed  by  an  NPS  student  on  the 
use  of  03b  to  enhance  throughput  for  Marine  Corps  missions  (Teichert,  2016).  The 
antenna  parameters  of  one  of  these  objects  are  displayed  in  Figure  28. 

Figure  28.  Antenna  Parameters  of  03b  Satellite.  Source:  Scalable  Network 

Technologies  (2016). 
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M003,  M007,  M009,  and  M011  were  the  03b  satellites  selected  to  provide 
coverage  over  the  San  Francisco  Bay  Area.  In  reality,  these  satellites  may  or  may  not 
have  spot  beams  positioned  to  cover  this  region.  The  assumption  is  that  with  a 
subscription  service  to  the  network,  03b  will  align  spot  beams  within  its  constellation  to 
provide  the  best  coverage  of  a  region.  The  satellite  objects,  equipped  with  parabolic 
dishes,  were  modeled  with  sensors  that  enabled  their  spot  beams  to  point  directly  at  the 
LCS  as  well  as  at  the  Vernon  ground  station.  In  a  real-world  environment,  the  LCS  may 
not  have  the  luxury  of  consistently  being  at  the  center  of  a  spot  beam.  Consequently,  the 
simulated  LCS  experienced  higher  antenna  gains  when  compared  to  real-world 
measurements;  this  was  indicated  by  comparing  Figure  25  and  Figure  26.  Each  satellite, 
with  two  attached  sensors  and  antennas,  was  able  to  point  at  Vernon  and  the  LCS  during 
access  windows  simultaneously.  There  was  a  sufficient  overlap  of  spot  beams  for 
handovers  to  occur  between  satellites.  In  the  QualNet  portion  of  the  simulation,  a  satellite 
object  was  modeled  with  two  STK  antennas  with  an  attached  interface  on  each.  The  two 
interfaces  are  configured  for  the  uplink  and  downlink  frequencies  of  the  LCS  and  Vernon 
gateway,  respectively. 

As  described  in  Chapter  II,  STK  handles  the  antenna  and  propagation  models, 
while  QualNet  handles  protocols  and  packets  in  the  OSI  layers.  Understanding  the 
relationship  between  the  two  programs  was  critical  in  configuring  the  ground  station  and 
satellite  connections.  The  benefit  of  the  STK/QualNet  interface  is  a  layout  that 
simultaneously  displays  objects  from  STK  and  nodes  from  QualNet.  Although  QualNet 
configuration  files  can  be  built  independently  and  loaded  into  STK,  it  is  not  a 
recommended  method  due  to  positional  misalignments  between  nodes  and  interfaces  that 
can  occur.  The  recommended  method,  according  to  the  QualNet  documentation,  is  to 
build  entire  STK/QualNet  scenarios  within  the  STK  VDL  (Scalable  Network 
Technologies,  2016).  The  STK/QualNet  interface,  while  intuitive  in  design  to  users 
familiar  with  each  separate  program,  does  not  offer  the  same  level  of  support  and 
functionality  when  compared  to  each  program  used  separately.  Lor  example,  QualNet 
offers  several  different  types  of  wireless  subnets  to  model  satellites,  but  not  all  will  run 
within  the  STK/QualNet  environment. 
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Initially,  the  Abstract  Network  Equation  (ANE)  satellite  model  was  built  into  the 
STK/QualNet  scenario  to  create  communications  between  the  LCS,  03b  Constellation, 
and  03b  ground  station.  The  QualNet  wireless  library  documentation  defines  ANE  as  a 
model  that  provides  an  advanced  set  of  tools  that  simplifies  modeling  spot-beam  satellites 
and  multiple  upstream  systems  (Scalable  Network  Technologies,  2016).  Despite  various 
attempts  to  integrate  it  into  the  STK/QualNet  scenario,  the  ANE  model  did  not  function 
properly.  Despite  extensive  troubleshooting,  the  issue  was  not  resolved,  and  the  ANE 
model  is  deemed  incompatible  with  the  STK/QualNet  interface  due  to  software  issues. 
The  STK/QualNet  interface  contains  a  running  log  for  viewing  script  changes  and  error 
messages  in  QualNet  processes.  Normally  when  running  a  scenario  containing  design 
errors,  the  simulation  will  automatically  cancel  and  fault  descriptions  will  be  displayed 
here.  However,  this  was  not  the  case  when  running  ANE  model  scenarios.  The  scenario 
would  remain  in  initialize  mode  indefinitely,  preventing  the  simulation  from  running  and 
providing  no  details  in  the  QualNet  log.  As  such,  it  was  impossible  to  determine  whether 
or  not  the  ANE  satellite  model  was  interoperable  with  STK. 

In  light  of  poor  success  with  the  ANE  model,  a  different  approach  was  used  in 
creating  satellite  links  between  the  LCS,  03b  Satellites,  and  the  ground  station.  Rather 
than  create  subnets  for  the  objects  to  pass  traffic,  a  more  direct  method  was  used  by 
establishing  wireless  links.  The  STK/QualNet  interface  supports  and  recognizes  point-to- 
point  links  between  nodes  and  interfaces.  These  links  use  QualNet’ s  Abstract  Link  MAC 
Model,  which  can  be  configured  for  wired,  wireless,  or  microwave  mediums  (Scalable 
Network  Technologies,  2016).  As  with  ANE,  there  were  limitations  in  the  performance 
of  these  links.  First,  a  point-to-point  link  only  connects  one  interface  on  a  node  to  one 
interface  on  another  throughout  the  entire  simulation.  This  one-to-one  limitation  did  not 
necessarily  prevent  scenario  one  from  running  but  created  the  need  for  many  more 
interfaces  than  intended.  For  example,  the  LCS  Ka-band  terminal  was  required  to  point  at 
multiple  03b  nodes  to  maintain  availability,  but  this  was  not  possible  with  a  single 
interface  on  the  antenna.  A  single  STK  object,  such  as  an  antenna,  can  have  multiple 
QualNet  interfaces  (or  “instances”)  assigned  to  it.  Multiple  interfaces  are  required  to  link 
the  LCS  or  ground  station  to  each  satellite  as  it  gained  access.  Scenario  one  was  capable 
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of  executing  and  collecting  statistics  with  this  configuration,  but  it  led  to  concerns  that 
the  additional  interfaces  may  introduce  errors.  Also,  having  too  many  interfaces  made  it 
very  time-consuming  to  make  the  slightest  of  changes  to  the  overall  model.  As  such,  the 
approach  reverted  to  using  wireless  subnets  to  link  satellite  and  ground  nodes  together. 

Further  research  into  STK/QualNet  interactions  revealed  that  the  QualNet 
Satellite-RSV  model,  one  of  multiple  models  available,  is  recognized  in  the  program’s 
operating  environment  with  STK  version  10.1.3  (Scalable  Network  Technologies,  2016). 
The  Satellite-RSV  model  is  unique  when  compared  to  other  wireless  models  insofar  as 
QualNet  defines  it  as  “multilayer” — meaning  multiple  OSI  layers  require  specific  settings 
for  it  to  function  properly.  The  basic  capabilities  of  the  Satellite-RSV  model  are  defined 
in  QualNet  documentation  as,  “The  Aloha  Satellite  Model  with  Reed-Solomon/Viterbi 
(RSV)  support  is  a  Demand  Assignment  Multiple  Access  (DAMA)  scheme  based  on  the 
Aloha  protocol.  The  model  operates  either  as  a  bent-pipe  satellite  or  as  a  satellite  with  an 
onboard  processor-payload”  (Scalable  Network  Technologies,  2016).  The  Aloha  Protocol 
is  used  on  older  generations  of  satellite  terminals  and  offers  simple  routing  at  the  MAC 
layer  by  broadcasting  data  when  data  is  received.  The  data  source  will  continue  to 
retransmit  at  random  intervals  if  an  acknowledgment  is  not  received.  With  STK/QualNet 
interoperability  and  the  bent-pipe  architecture  of  03b’ s  constellation  in  mind,  the  satellite 
RSV-model  was  best  suited  for  simulating  and  forwarding  data  received  by  the  LCS  to 
the  Vernon  ground  station. 

Implementing  the  Satellite-RSV  model  in  STK/QualNet  required  adjusting 
settings  on  two  OSI  layers.  First,  the  radio  type  at  the  physical  layer  of  a  nodal 
interface — whether  ground  or  satellite — was  set  to  Satellite-RSV,  and  the  listenable 
channels  (uplink  and  downlink)  configured  according  to  transmit  and  receive  frequencies 
of  the  antenna  objects.  Next,  the  routing  protocol  of  the  MAC  layer  is  set  to  Satellite- 
RSV,  and  the  protocol  role  was  designated  as  a  ground  station  or  satellite.  The  uplink  and 
downlink  channels  of  the  interface  are  also  established  in  this  submenu  as  well  as 
optional  parameters  such  as  cross  channel  interference,  noise  and  more.  Although  it  is 
possible  to  configure  a  QualNet  nodal  interface  to  be  satellite-RSV  at  the  physical  layer, 
with  a  different  routing  protocol  at  the  data/MAC  layer,  the  configuration  is  not 
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recommended.  The  QualNet  documentation  states  that  the  satellite-RSV  model  at  the 
physical  layer  should  only  be  used  in  conjunction  with  the  same  model  at  the  data/MAC 
layer  for  optimal  performance.  The  configuration  of  the  scenario  channels  is  displayed  in 
Figure  29. 


Figure  29.  Scenario  1  Channel  Configuration 
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The  configuration  steps  at  the  physical  and  MAC  layers  are  completed  for  each 
ground  station  and  satellite  object  interface.  Two  satellite-RSV  wireless  subnets,  one  for 
the  LCS  Ka-band  terminal  and  one  for  the  Vernon  ground  station,  were  configured  with 
the  RSV-satellite  model  at  the  physical  layer  and  MAC  sublayer  once  all  interfaces  are 
established.  The  two  subnets  linked  all  IGW  objects  and  interfaces  within  the  scenario 
and  prevented  them  from  overlapping  on  downlink  and  uplink  frequencies.  One 
observation  noted  with  an  RSV-satellite  wireless  subnet  was  that  it  did  not  retroactively 
enact  global  updates  to  interfaces  under  its  hierarchy  if  changes  are  made  to  any  setting. 
It  is  uncertain  whether  this  was  an  intentional  design  of  QualNet  or  oversight.  In  any 
case,  minor  modifications  made  to  properties  in  the  Satellite-RSV  subnet  required  the 
user  to  go  back  and  manually  change  all  interfaces  in  the  hierarchy  to  match. 
Discrepancies  in  uplink  and  downlink  channels  between  the  subnet  properties  and  nodal 
interfaces  sometimes  caused  the  STK/QualNet  program  to  crash  or  the  scenario  to 
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initialize  indefinitely.  As  with  the  ANE  satellite  model,  the  crashes,  and  endless 
initialization  prevent  the  QualNet  log  from  updating,  making  in-depth  troubleshooting 
difficult  if  not  impossible. 

Next  generation  satellite  terminals,  such  as  those  used  by  03b,  typically  use 
TDMA  or  CDMA  protocols  on  coding/decoding  devices  connected  to  the  terminal.  It  was 
possible,  but  not  practical,  to  mix  the  satellite-RSV  physical  model  with  a  TDMA  routing 
protocol  at  the  MAC  layer.  However,  to  achieve  the  best  interoperability  with  STK  and 
QualNet,  the  satellite-RSV  model  was  used  on  the  first  two  layers  on  every  satellite 
interface  and  subnet.  This  configuration  appeared  to  be  the  closest  match  to  03b’ s  bent- 
pipe  architecture  that  could  be  designed  in  the  simulation.  An  additional  benefit  was  the 
relative  simplicity  of  the  model  when  compared  to  the  previous  attempts.  The  STK 
antenna  objects  on  each  node  required  one  QualNet  interface  vice  the  many  of  a  point-to- 
point  configuration  providing  concise  statistics  output  and  narrowed  down 
troubleshooting  paths  when  issues  arose. 

The  scenario  is  concluded  after  statistics  are  gathered  for  one  orbital  period  of 
03b’s  satellites. 

D.  SCENARIO  2:  LCS  PERFORMING  AS  A  ROUTER 

The  LCS  performing  as  a  router  was  designed  in  the  STK/QualNet  interface  with 
simulation  models  available  in  the  QualNet  LTE  Library.  The  premise  of  the  scenario  is 
that  an  LCS,  using  organic  assets,  is  tasked  with  conducting  a  compliant  VBSS  boarding 
in  the  littorals.  The  nodes  used  in  this  scenario  are  the  LCS,  two  Rigid  Hull  Inflatable 
Boats  (RHIBS),  and  an  RQ-8A  Lire  Scout.  All  nodes  are  connected  via  a  self-contained 
4G  LTE  bubble  generated  by  external  antennas  mounted  on  the  LCS.  The  Lire  Scout  is 
equipped  with  a  commercially  available  4G  LTE  video  camera  used  to  stream  video  back 
to  the  LCS  and  boarding  teams.  The  networking  equipment  on  the  LCS  is  an  LTE  core 
server  that  can  theoretically  share  data  with  the  ship’s  ADNS  network  to  complete  back¬ 
haul  to  the  shore  side.  The  modeling  of  the  long-haul  throughput  with  4G  LTE  was 
beyond  the  scope  of  this  scenario.  The  focus  was  on  the  performance  of  the  LCS  as  a 
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major  node  using  the  LTE  networking  technology  to  form  a  MANET  in  the  local 
environment.  The  total  scenario  time  was  approximately  three  hours. 

In  LTE  terminology,  the  LCS  and  connected  nodes  formed  an  Evolved  Packet 
Core  (EPC)  subnet.  The  LCS  was  configured  as  the  evolved  Node  B  (eNB)  or  base 
station.  The  other  nodes  were  set  up  as  User  Equipment  (UE).  As  there  was  only  one  base 
station,  the  availability  metric  in  this  scenario  was  the  number  of  packets  received  and 
sent — handovers  between  base  stations  was  excluded. 

The  premise  of  the  scenario  is  that  a  cargo  vessel,  designated  as  a  Vessel-of- 
Interest  (VOI),  is  transiting  through  the  littoral  regions  near  Yerba  Buena  Island.  The 
LCS  is  given  permission  to  search  the  vessel  by  the  MIO  commander.  To  conduct 
surveillance  and  reconnaissance  (SAR)  of  the  vessel  before  boarding,  the  LCS  launches 
its  RQ-8A.  The  airborne  platform  performs  a  sweep  of  the  area  and  discovers  the  cargo 
vessel  transiting  due  North.  Once  it  locates  the  cargo  ship,  the  RQ-8A  trails  it  and  begins 
to  stream  live  video  back  to  the  LCS  through  the  LTE  bubble.  The  camera  selected  for 
use  on  the  RQ-8A  was  an  LG  LTE  Action  Camera;  this  device  does  not  require  tethering 
to  a  handheld  device  to  function  in  the  bubble.  The  following  are  the  camera’s 
specifications,  and  Ligure  30  shows  the  compact  form  factor  of  the  device. 

•  Camera:  1/2.3-inch  12.3MP  (150-degree  wide  angle  lens)  /  1.55  x  1.55/tm 
pixels 

•  Video  Recording:  UHD  30fps  /  Lull  HD  30,  60fps  /  HD  30,  60,  120fps 

•  Video  Live  Streaming:  HD  (up  to  30fps) 

•  Chipset:  Qualcomm®  Snapdragon™  650  Processor 

•  Memory:  2GB  RAM  /  4GB  ROM  (OS  only)  /  microSD  (up  to  2TB) 

•  Size:  35  x  35  x  79.7mm 

•  Weight:  99g 

•  Others:  IP67  /  GPS  /  Accelerometer  /  Gyroscope  (LG  Newsroom,  2016) 
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Figure  30.  LG  Action  Camera.  Source:  LG  Newsroom  (2016). 


In  the  scenario,  once  the  RQ-8A  detects  the  cargo  vessel,  the  LCS  repositions  to 
launch  the  RHIBs  and  conduct  the  boarding.  While  the  VBSS  team  members  are 
preparing  for  launch,  they  can  view  images  and  live  video  of  the  VOI  through  LTE 
enabled  handheld  devices.  After  the  RHIBs  are  launched  and  approach  the  VOI,  the 
teams  can  maintain  SA  via  the  RQ-8A  streaming  video  back  to  the  LCS.  The  device  used 
by  the  VBSS  team  members  was  the  Samsung  Galaxy  Note  II  LTE.  The  following  are 
some  of  the  specifications  of  this  device: 

•  Display:  16M  Color  HD  SUPER  AMOLED,  16:9  Full  Touch  Display 

•  Size  5.55,”  Resolution  1280  x  720pixel 

•  Dimension  (WxHxD)  80.5  x  151.1  x  9.45mm 

•  Weight  182g 

•  Band  FDD-LTE  (800/900/1 800/2600MHz)  +  WCDMA 

(850/900/2 100MHz)  +  GSM  (850/900/1 800/1900MHz) 

•  Processor  1.6GHz  Quad-Core  Processor 

•  Data  Transfer  LTE  100Mbps  /  HSDPA+  42Mbps  /  HSUPA  5.76Mbps 

•  Video  Play  Format  H.263  /  H.264  /  WMV  /  MPEG4  /  DivX  /  AVI  /  FLV 

•  Video  Recording  1280  x  720  pixels  (30fps) 

•  Recording  Mode:  Slow  Motion  and  Fast  Motion 

•  Camera  Resolution  8.0  Megapixel  Auto  Focus  Camera 

•  Front  Camera  1.9  Megapixel  (Samsung,  n.d.) 
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The  Samsung  Galaxy  Note  II  used  by  VBSS  members  is  displayed  in  Figure  31. 
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Samsung  Galaxy  Note  II.  Source:  Samsung  (n.d.). 
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The  RQ-8A  remains  on  station  until  its  fuel  is  nearly  expended,  at  which  point  it 
returns  to  the  LCS.  Once  the  RHIBs  detach  from  the  cargo  vessel,  the  scenario  ends. 

E.  SCENARIO  3:  LCS  PERFORMING  AS  A  HUB 

The  LCS  performing  as  a  hub  in  this  scenario  used  network  nodes  with  the  same 
radio  and  satellite  equipment  as  Scenario  1 .  The  goal  in  this  scenario  was  to  observe  LCS 
network  performance  when  receiving  and  distributing  data  originating  from  the  shore 
side.  In  essence,  the  data  flow  shifted  to  nodes  receiving  the  majority  of  traffic  rather  than 
sending  it.  The  metric  used  to  determine  the  effectiveness  was  once  again  availability 
over  a  six  hour  period.  The  availability  can  be  viewed  from  an  end-to-end  perspective, 
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comparing  total  broadcast  packets  sent  from  Vernon  with  the  number  received  at  each 
node. 

In  addition  to  the  nodes  in  Scenario  1,  the  CG  and  DDG  each  launched  a  RHIB  to 
conduct  picket  boat  operations  on  the  outskirts  of  the  operational  boxes.  The  RHIBs  were 
equipped  with  handheld  isotropic  2.4  GHz  Wave  Relay  radios.  Cargo  vessels  were 
modeled  into  the  scenario  transiting  on  a  traffic  separation  scheme  into  and  out  of  the  SF 
Bay  near  the  operational  area.  The  LCS  in  the  scenario  broadcasts  information  regarding 
the  traffic  of  vessels  and  VOIs  to  all  nodes  within  the  mesh,  as  received  from  the  Vernon 
Ground  Station. 

A  broadcast  IP  address  was  assigned  to  one  of  the  RHIBs  to  make  the  LCS 
forward  packets  to  all  nodes  on  the  Wave  Relay  subnet. 

F.  SCENARIO  4:  LCS  PERFORMING  AS  A  BRIDGE 

The  LCS  in  this  scenario  performed  as  a  bridge  between  two  networks  through 
multiple  point-to-point  microwave  links.  The  scenario  consisted  of  three  LCS  platforms; 
one  behaving  as  the  major  node  and  the  other  two  serving  as  control  stations  for 
unmanned  assets.  The  first  of  the  LCS  control  stations  launched  two  RQ-8As  and 
received  data  collected  from  their  organic  sensors;  this  data  was  fed  to  the  organic  ship’s 
network.  The  next  LCS  control  station  performed  the  same  function,  but  with  USVs. 
Ideally,  a  Sea  Fox  USV  would  have  been  used  if  the  model  was  available  through  STK 
downloadable  resources.  At  the  time  of  this  thesis,  the  USV  model  available  in  STK  that 
closely  resembled  the  Sea  Fox  was  the  High-Speed  Maneuvering  Surface  Target 
(HSMST).  This  vessel  is  capable  of  being  manned  or  remotely  operated  and  is  typically 
used  for  force  protection  and  gunnery  exercises.  For  simulation  purposes,  it  was  remotely 
operated. 

Tsunami  QB-10100  Point-to-Point  Wireless  Bridge  Bundles  were  modeled  into 
the  simulation  to  create  a  network  bridge  between  the  LCS  subnets  containing  the 
unmanned  nodes  via  the  major  node  LCS.  In  total,  four  Tsunami  QB-10100  were 
modeled  into  the  scenario;  two  on  the  major  node  LCS,  and  one  on  each  control  station 
LCS.  The  scenario  duration  was  three  hours.  Unlike  previous  scenarios,  the  nodes 
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remained  close  together  and  on  logical  paths  and  trajectories  throughout;  this  design 
reflected  the  need  to  have  nodes  pointing  in  specific  directions  to  bridge  the  networks. 
Aside  from  the  US  Vs,  all  nodes  used  directional  microwave  antennas.  The  measure  of 
availability  was  observed  by  sending  a  constant  bit  rate  from  an  unmanned  asset  on  one 
subnet  to  the  LCS  on  a  different  subnet.  The  parameters  of  the  TCDL  links  used  for  the 
Fire  Scouts  are  displayed  in  Figure  32  and  Figure  33. 


Figure  32.  Fire  Scout  STK  TCDL  Antenna  Parameters.  Source:  Scalable 

Network  Technologies  (2016). 
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Figure  33.  LCS  Control  Station  STK  TCDL  Antenna  Parameters.  Source 

Scalable  Network  Technologies  (2016). 
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The  parameters  for  the  Tsunami  Point-to-Point  wireless  network  bridge  are 
displayed  in  Figure  34. 


Figure  34.  Tsunami  Point-to-Point  Wireless  Network  Bridge  STK  Parameters. 

Source:  Scalable  Network  Technologies  (2016). 
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G.  XATA  5.3  CONCEPTUAL  EXPERIMENT 

The  experiment  for  testing  network  management  software  on  the  LCS  was 
designed  to  use  two  workstations,  IT140321  and  IT140717,  available  in  the  CENETIX 
Lab  at  NPS.  The  software  tools  used  were  EXata  5.3,  QualNet  7.3,  and  STK  10.1.3.  The 
network  management  tools  acquired  were  SolarWinds  Network  Performance  Monitor 
(NPM)  and  Network  Configuration  Manager  (NCM).  The  biggest  challenge  in  setting  up 
the  experiment  was  overcoming  licensing  hurdles.  The  SolarWinds  tools  offered  a  30-day 
free  trial,  while  Scalable  Networks  offered  a  two-week  trial  version  of  EXata  5.3.  The 
license  files  for  QualNet  7.3  and  STK  10.1.3  did  not  cause  any  issues  since  they  are 
maintained  through  an  educational  agreement  with  NPS. 
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As  illustrated  in  Chapter  II,  the  primary  benefit  of  EXata  over  QualNet  is  its 
ability  to  run  an  emulated  network  testbed  indefinitely.  Also,  it  allows  a  user  to  create 
both  emulated  nodes  and  simulated  nodes  within  the  testbed.  An  emulated  node  is  a 
device,  real  or  virtual,  which  can  connect  and  interact  with  simulated  nodes.  The 
simulated  nodes  are  the  same  as  those  found  in  QualNet  7.3.  The  applications  that  can  be 
run  on  an  emulated  node  are  constrained  only  by  the  capabilities  of  the  system 
performing  this  role.  To  connect  an  emulated  node  to  the  testbed,  a  Scalable  Networks 
application  called  Connection  Manager  is  installed  on  IT140321;  this  enabled  it  to 
perform  as  an  operational  host  on  the  network.  EXata  5.3  was  installed  on  IT  1407 17,  and 
a  Connection  Manager  internal  to  this  application  was  used  to  identify  devices  capable  of 
serving  as  an  operational  host.  An  overview  of  an  emulated  testbed  is  illustrated  in 
Figure  35. 

Figure  35.  Conceptual  Emulated  Testbed  with  Operational  Hosts.  Source: 

Scalable  Network  Technologies  (2014a). 
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By  design,  the  machine  running  EXata  5.3  was  unable  to  run  other  applications  as 
emulated  nodes  within  the  testbed  while  running  an  emulated  scenario.  This  point  was 
important  to  keep  in  mind  because  any  software  or  application  to  be  run  on  an  emulated 
node  needed  to  be  installed  on  a  machine  separate  from  the  EXata  machine.  Therefore, 
the  SolarWinds  tools  were  installed  on  IT140321.  To  inject  a  simulated  LCS  into  the 
emulated  testbed,  a  separate  scenario  had  to  be  built  and  saved  by  using  the  STK/QualNet 
interface  on  either  machine.  When  a  scenario  is  made  using  STK/QualNet,  a  separate 
application  and  configuration  file  for  STK  and  QualNet  is  created,  respectively.  The 
QualNet  configuration  file  created  from  the  STK/QualNet  mapping  can  then  be  loaded 
into  EXata.  The  configuration  file  carries  over  the  majority  of  parameters  from 
STK/QualNet  to  EXata,  in  particular,  the  location  of  the  nodes. 

For  the  conceptual  experiment,  to  test  the  network  management  capabilities  of  the 
LCS,  the  QualNet  configuration  files  from  scenarios  1  through  4  can  be  loaded  into  the 
EXata  environment.  The  simulated  node  designated  as  the  LCS  in  the  STK/QualNet 
interface  can  then  be  changed  to  an  emulated  node.  The  simulated  nodes  in  the  testbed 
can  be  given  SNMP  agents  that  allow  network  management.  SolarWinds  network 
management  tools,  connected  to  the  LCS’  emulated  node  via  operational  host  IT140321, 
can  be  used  to  monitor  and  configure  the  simulated  nodes  with  the  SNMP  capability  set. 
The  simulated  nodes  with  SNMP  capability  can  also  be  loaded  with  network  management 
configuration  files  to  define  Management  Information  Base  (MIB)  structure  and  entities. 
EXata  5.3  offers  compatibility  with  most  variants  of  SNMPvl  through  SNMPv3.  With 
the  LCS  emulated  node  performing  as  the  manager,  it  is  possible  for  it  to  identify  and 
manage  nodes  using  third-party  network  management  tools  such  as  SolarWinds. 
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IV.  STK  DATA  COLLECTION  AND  ANALYSIS 


A.  SCENARIO  1  DATA:  LCS  PERFORMING  AS  A  GATEWAY 

Initially,  a  major  shortfall  in  the  LCS  as  Gateway  scenario  was  the  inability  to 
realistically  model  the  Wave  Relay  devices  in  the  STK/QualNet  environment  (Figure  35). 
Table  6  shows  the  nodes  used  in  this  scenario.  The  majority  of  802.11  signals  transmitted 
by  the  destroyer  and  cruiser  were  detected  by  the  LCS,  but  few  of  the  signals  were  locked 
on.  The  inability  to  lock  on  caused  the  AODV  routing  protocol  to  search  for  new  routes 
and  to  eventually  drop  packets  due  to  a  perceived  lack  of  viable  route.  Nodes  were  able  to 
maintain  connection  and  transfer  data  only  at  very  close  ranges,  approximately  half  a 
kilometer.  The  scenario  1  overview  is  displayed  in  Figure  36  and  participating  nodes  are 
listed  in  Table  6. 


Figure  36.  Scenario  1  Overview.  Source:  Scalable  Network 

Technologies  (2016). 
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Table  6.  Scenario  1  Nodes 


QualNet 

Node  ID 

STK  Platform 

T  ype/Model/De  scrip  tion 

STK 

Antenna/Sensor 

QualNet  PHY 

Model 

QualNet 

Subnet 

5 

Ship/CG  3D 

Model/Ticonderoga 

Class  CG 

Rectangular 

Pattern 

802.1  la/g 

192.168.86.0 

6 

Ship/DDG  3D 

Model/ Arleigh  Burke 

Class  DDG 

Rectangular 

Pattern 

802.1  la/g 

192.168.86.0 

7 

Ship/LCS  3D 

Model/Freedom  Class 

LCS 

Rectangular 

Pattern, 

Parabolic,  Fixed 

Target  Sensor 

802.1  la/g, 

Satellite-RSV 

192.168.86.0, 

190.0.3.0 

23 

Place/Facility /03b 

Ground  Station 

Parabolic 

Satellite-RSV 

190.0.2.0 

11 

Satellite/M003/03b 

MEO 

Parabolic,  Fixed 

Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

15 

Satellite/M007/03b 

MEO 

Parabolic,  Fixed 

Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

17 

Satellite/M009/03b 

MEO 

Parabolic,  Fixed 

Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

19 

Satellite/MOl  l/03b 

MEO 

Parabolic,  Fixed 

Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 
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The  solution  was  to  change  some  of  the  default  parameters  within  the  OSI  layer 
options  of  QualNet  to  improve  performance.  The  two  most  notable  improvements  were 
achieved  by  enabling  Logical  Link  Control  (LLC)  and  adjusting  the  MAC  Propagation 
Delay  parameter  in  STK/QualNet  from  the  default  setting  of  1  microsecond  to  100 
microseconds.  LLC  enables  error  and  flow  control  at  the  Data  Layer  while  changing  the 
propagation  delay  was  assumed  to  decrease  the  saturation  of  the  established  data  links. 
Based  on  manufacturer’s  specifications  of  the  Sector  Array  Antennas  and  radio  devices, 
as  well  as  previous  field  experimentation  conducted  by  the  NPS  CENETIX  team,  the 
Wave  Relay  devices  in  the  simulation  performed  realistically  when  all  factors  were 
considered.  With  the  simulation  parameters  as  described,  the  Wave  Relay  devices  on  the 
ships  were  able  to  transmit  and  receive  unicast  packets  at  ranges  of  over  3  kilometers. 
The  same  equipment  parameters,  when  placed  on  stationary  land  devices  in  the 
simulation,  were  able  to  achieve  unicast  packet  reception  at  ranges  of  over  10  kilometers 
— near  the  ranges  listed  in  the  manufacturer’s  specifications  (Persistent  Systems,  2015). 
The  success  using  land  devices  demonstrated  the  impact  environmental  factors  such  as 
sea  state  and  mobility  had  on  the  nodes.  As  such,  it  was  determined  that  the  observed 
operating  ranges  were  accurate  for  the  purpose  of  this  research.  The  effective  ranges  were 
measured  by  having  a  node  traverse  in  a  straight  path  away  from  the  LCS  while  running  a 
wireless  CBR  application.  The  CBR  application  was  set  to  transmit  an  item  at  1-second 
intervals  throughout  the  analysis  period.  The  distance  between  the  location  of  the 
transmitting  node  and  the  LCS  was  measured  at  the  recorded  time  that  the  last  unicast 
packet  was  received. 

The  mounting  parameters  of  the  Wave  Relay  antennas  had  only  a  slight  effect  on 
the  overall  performance.  As  described  in  Chapter  III,  the  antennas  were  mounted  on  the 
flight  decks  of  the  vessel  to  simulate  an  ad-hoc  experiment.  The  ship  nodes  were  able  to 
communicate  with  one  another  when  within  range,  and  also  use  other  nodes  as  hops  when 
a  node  was  out  of  range. 

Data  collection  centered  on  the  availability  and  throughput  of  the  mesh  network 
by  observing  how  the  nodes  in  the  Wave  Relay  and  03b  subnets  performed.  First,  to 
observe  availability,  a  CBR  application  at  low  data  rates  was  set  to  run  throughout  the 
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duration  of  the  analysis  period.  For  this  scenario,  it  was  configured  to  send  56  bytes  of 
data  at  1-second  intervals,  for  a  total  duration  of  21,600  seconds  (6  hours,  the  length  of 
the  STK  analysis  and  satellite  orbital  period).  To  calculate  the  percentage  of  availability, 
the  total  number  of  unicast  packets  sent  from  the  originating  node(s)  was  compared  to  the 
total  number  of  unicast  packets  received  at  the  end  node. 

The  FTP  application  was  set  to  run  from  the  start  of  the  scenario  to  the  end.  By 
selecting  1  second  as  the  start  time  and  21,600  seconds  as  the  end  time,  it  sent  files  of  a 
prescribed  size  (20  MB)  at  random  time  intervals.  The  maximum  number  of  files  to  be 
sent  can  be  specified,  but  this  does  not  guarantee  that  exact  number  will  be  sent.  By 
adjusting  the  number  of  items  to  be  sent  to  0,  the  simulation  will  send  a  random  number 
of  items  throughout  the  iteration.  This  methodology  was  used  in  this  scenario,  but  not  for 
every  following  scenario. 

The  first  CBR  application  measured  availability  from  each  node  in  the  mesh  to 
the  LCS.  The  second  CBR  application,  run  in  a  separate  iteration,  measured  the 
availability  of  the  LCS  to  the  03b  ground  station.  The  third  CBR  application  measured 
the  availability  of  the  DDG  and  CG,  using  the  LCS  as  an  IGW  to  the  03b  ground  station. 
The  STK/QualNet  stat  output  file  measures  simulation  results  in  an  aggregate  format. 
The  output  for  the  DDG  sending  unicast  segments  to  the  LCS  is  displayed  in  Figures  37 
and  38.  The  remaining  simulation  data  will  be  placed  in  tables  that  are  addressed  later  in 
this  section. 
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Figure  37.  Total  Unicast  Messages  Sent  from  CG  and  DDG  to  LCS 
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Figure  38.  Total  Unicast  Messages  Received  by  LCS  from  CG  and  DDG 
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The  LCS  to  the  03b  ground  station  used  the  satellite  nomenclatures  described  in 
Chapter  III.  Many  challenges  were  faced  in  establishing  end-to-end  connectivity  with  the 
satellite  links  and  supporting  nodes.  The  experiment  design  posited  to  use  OLSR  routing 
protocols  among  all  03b  satellite  and  ground  interfaces,  while  ship  nodes  in  the  mesh 
routed  with  AODV.  No  packets  were  received  at  the  ground  station  when  running  this 
configuration.  Further  examination  revealed  that  in  order  to  enable  communications 

between  different  protocols,  a  Border  Gateway  Protocol  (BGP)  was  needed.  A  BGP  and 
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multiple  network  hierarchies  (Autonomous  Systems)  can  be  established  in  the  standalone 
version  of  QualNet,  but  a  method  for  doing  this  in  the  STK/QualNet  interface  was  not 
discovered,  and  it  was  assumed  to  be  a  limitation.  That  being  said,  for  the  remaining 
scenarios  it  was  assumed  that  STK/QualNet  only  allowed  for  a  single  network  hierarchy 
and  hence  the  nodes  were  assigned  the  same  routing  protocols. 

To  create  end-to-end  connectivity  between  nodes  and  the  ground  station,  AODV 
is  enabled  on  every  node.  A  duplicate  scenario  was  run  using  the  OLSR  network  protocol 
on  all  nodes  and  the  results  were  compared  to  the  original  scenario  to  test  the  impact  of 
this.  The  difference  was  slight;  the  AODV-enabled  ground  station  received  about  ten 
more  total  unicast  packets  than  OLSR  over  the  course  of  the  entire  scenario. 

The  last  limitation  identified  was  that  the  LCS  could  only  use  one  of  its  Ka-band 
terminals  to  connect  to  the  satellite  constellation.  A  suitable  method  for  creating  a 
handover  between  the  Ka-band  terminals  as  they  locked  onto  satellites  was  not  found. 
The  additional  terminal  caused  issues  with  the  LCS  satellite  uplink  and  downlink 
channels.  As  such,  the  additional  terminal  was  left  in  the  STK  portion  of  the  scenario  for 
visual  purposes  but  was  not  mapped  to  a  QualNet  interface. 

In  addition  to  the  Wave  Relay  subnet,  the  final  working  configuration  of  the  LCS 
communications  path  to  the  ground  station  used  two  subnets:  one  for  the  LCS  Ka-Band 
terminal  to  the  03b  satellite  interfaces,  and  one  for  the  Vernon,  Texas  ground  station  to 
03b  satellite  interfaces.  The  simulation  results  are  displayed  in  Table  7,  Table  8,  and 
Table  9. 
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Table  7.  Scenario  1  Availability 


Application 

Originating 

Receiving 

Data  Tx 

Data  Rx 

Availability 

Node 

Node 

CBR 

7  (LCS) 

23  (Vernon) 

21,599 

16,624 

76.9% 

Unicast 

Unicast 

Segments 

Segments 

CBR 

5  (CG) 

7  (LCS) 

21,599 

5,253 

24.3% 

Unicast 

Unicast 

Segments 

Segments 

CBR 

6  (DDG) 

7  (LCS) 

21,599 

6,391 

29.6% 

Unicast 

Unicast 

Segments 

Segments 

CBR 

5  (CG) 

23  (Vernon) 

21,599 

4,050 

18.8% 

Unicast 

Unicast 

Segments 

Segments 

CBR 

6  (DDG) 

23  (Vernon) 

21,599 

4,460 

20.6% 

Unicast 

Unicast 

Segments 

Segments 

Table  8.  Scenario  1  FTP  Throughput 


Application 

Originating 

Node 

Receiving 

Node 

Data  Tx 

Data  Rx 

Throughput 

Tx 

Throughput 

Rx 

FTP 

5  (CG) 

23  (Vernon) 

60  MB 

40MB 

2.8  KB/s 

1.85  KB/s 

FTP 

6  (DDG) 

23  (Vernon) 

140  MB 

120MB 

6.48  KB/s 

5.56  KB/s 
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Table  9.  Scenario  1  Network  IP  Carried  Load  (Bytes/Second) 


Node  ID 

5 

6 

7 

11 

15 

17 

19 

23 

Carried  Foad 

2,277 

6,086 

65,848 

484 

7,834 

668 

21,257 

738 

The  super  application,  as  described  in  Chapter  II,  would  have  been  useful  in 
testing  throughput  capabilities  of  the  network  by  injecting  video  and  voice  data  streams 
into  the  mesh.  Unfortunately,  this  application  would  not  run  without  crashing  the 
scenario.  The  scenario  would  cancel  upon  running,  and  the  QualNet  log  file  would 
generate  a  list  of  parameters  needed  to  be  set  for  the  application  to  run  successfully.  Even 
when  the  application  parameters  were  set  accordingly,  the  STK/QualNet  environment 
would  not  detect  them. 

As  a  result,  the  CBR  and  FTP-generic  applications  were  used  exclusively  for  the 
remainder  of  the  research.  These  applications  had  the  highest  level  of  stability  in  the 
STK/QualNet  environment.  Even  so,  the  FTP-generic  application  would  sometimes  crash 
the  simulation  when  a  large  number  of  files,  sizes  ranging  from  2  MB  to  20  MB,  were 
sent.  These  findings  made  it  appear  that  certain  limits  existed  on  the  amount  of  network 
data  that  could  be  simulated  and  collected.  The  bounds  of  these  limits  were  not  known, 
and  it  was  beyond  the  scope  of  the  research  to  identify  them. 

From  the  data  collected  with  FTP  and  CBR,  the  availability  and  throughput 
during  the  period  of  analysis  were  unacceptably  low  from  a  customer  or  warfighter 
standpoint.  However,  this  was  somewhat  expected  as  the  nodes  were  set  to  move 
randomly  within  their  operational  boxes  to  observe  data  links  breaking  and  reforming. 
For  the  Wave  Relay  devices,  if  the  nodes  moved  in  an  established  formation  to  maintain 
effective  ranges  then  the  results  would  likely  improve.  The  superstructure  of  the  ships  in 
the  simulation  appeared  to  have  a  large  effect  on  RF  reception  as  well  —  placing  an 
antenna  too  close  to  the  skin  of  a  node  resulted  in  degraded  performance,  if  not  blocking 
it  completely.  As  such,  experiments  mounting  Wave  Relay  antennas  on  high  points  of  the 
node  enabled  better  360-degree  coverage.  Fastly,  the  CBR  applications  were  sent  from 
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the  DDG  and  CG  simultaneously,  which  resulted  in  slightly  degraded  performance 
compared  to  each  node  sending  them  at  individual  times. 

The  satellite  communications  may  have  experienced  degraded  availability  for 
several  reasons.  Fortunately,  the  QualNet  statistics  file  generates  network  information 
specific  to  satellite  performance.  The  Satellite-RSV  bent-pipe  model  displays  information 
about  packets  utilizing  uplink  and  downlink  channels,  as  well  as  average  Eb/No  for  each 
satellite  interface.  In  scenario  1,  the  LCS  sent  21,599  unicast  packets  to  the  ground 
station.  Of  these  packets,  only  18,125  made  it  off  the  ship  through  the  uplink  channel 
between  the  LCS  Ka-band  terminal  and  the  03b  constellation.  Furthermore,  only  16,624 
were  received  at  Vernon,  Texas.  The  frequencies  and  parameters  of  the  satellite  links 
may  have  been  partly  to  blame.  Also,  the  single  Ka-band  terminal  needed  to  switch  to  a 
new  satellite  without  a  seamless  handover.  This  error  was  also  replicated  at  the  Vernon 
ground  station  whenever  it  needed  to  lock  on  to  a  new  satellite.  If  this  was  the  case,  the 
availability  could  be  improved  by  finding  a  method  to  enable  handovers  to  occur. 

The  second  area  to  examine,  the  average  Eb/No  for  each  satellite,  can  be 
measured  by  observing  the  performance  of  the  LCS  during  a  satellite’s  access  window. 
The  Eb/No  graphic  displays  information  on  the  LCS  and  Vernon  interface  of  each 
satellite.  On  interface  17(0),  the  03b  antenna  linking  to  the  LCS  1.2M  terminal,  an 
average  Eb/No  of  -38.9  dB  was  recorded.  During  the  access  window,  it  was  suspected 
that  the  Ka-band  terminal  on  the  LCS  was  transmitting  into  the  hull  of  the  LCS.  The 
QualNet  average  Eb/No  and  STK  access  window  are  displayed  in  Ligure  39  and 
Ligure  40. 
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Figure  39.  Scenario  1  03b  Ground  Station  and  Satellite  QualNet  Eb/No 
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The  access  summary  report  shows  the  period  in  the  scenario  where  the  LCS  uses 
satellite  M009  as  its  network  link  to  the  ground  station.  In  STK,  skipping  to  the 
timeframe  of  interest  reveals  that  the  Ka-band  terminal  may  have  experienced  blockage 
due  to  the  LCS  superstructure.  This  is  displayed  in  Figure  41. 


Figure  41.  LCS  during  Satellite  M009’s  Access  Window 


The  main  observations  from  scenario  1  were  that  for  the  LCS  to  be  an  effective 
IGW,  the  connected  nodes  in  the  mesh  must  be  aware  of  the  effective  ranges  of  the  Wave 
Relay  equipment  and  reposition  themselves  accordingly.  The  lower  than  expected 
satellite  availability  appears  to  be  a  function  of  limitations  imposed  by  the  manner  in 
which  the  scenario  was  designed,  as  well  as  a  lack  of  handover  capability  between 
ground  terminals  in  STK/QualNet. 

B.  SCENARIO  2  DATA:  LCS  PERFORMING  AS  A  ROUTER 

The  original  design  of  LCS  as  Router  scenario  posited  to  employ  the  QualNet  LTE 
Physical  and  MAC  layer  models  to  create  a  4G  LTE  bubble  around  the  LCS  that  allowed 
nodes  within  to  communicate  with  one  another  (Figure  42).  Table  10  shows  the  nodes 
used  in  the  scenario.  It  was  discovered  after  much  trial  and  error  that  the  LTE  portion  of 
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QualNet  was  not  compatible  with  the  STK/QualNet  environment.  The  reason  an  EPC 
network  could  not  be  established  is  that  a  Core  Network  (CN)  must  be  connected  to  an 
802.3  wired  network  and  a  SGWMME  (in  the  form  of  a  hub  or  router).  This  requirement 
cannot  be  modeled  in  STK/QualNet,  as  only  wireless  subnets,  links,  and  wired  links  can 
be  modeled.  The  model  in  Figure  42  displays  the  components  necessary  for  LTE  to 
function  in  QualNet  7.3. 

Figure  42.  Scenario  2  Overview.  Scalable  Network  Technologies  (2016). 


San  Francisco,  CA 
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Scenario  2  nodes  and  additional  information  about  the  nodes  is  displayed  in 
Table  10. 


Table  10.  Scenario  2  Nodes 


QualNet 

Node  ID 

STK  Platform 

T  ype/Model/De  scription 

STK 

Antenna/Sensor 

QualNet  PHY 

Model 

QualNet 

Subnet 

7 

Ship/LCS  3D 

Model/Freedom  Class 

LCS 

Isotropic 

802.11b 

190. 0.x. x 

9 

Ship/Rubber  Boat  3D 

Model/RHIB  1 

3cm  Dipole 

802.11b 

190.0.1.0 

5 

Ship/Rubber  Boat  3D 

Model/RHIB  2 

3cm  Dipole 

802.11b 

190.0.2.0 

8 

Aircraft/RQ-8A  3D 

Model/Fire  Scout 

3cm  Dipole 

802.11b 

190.0.3.0 
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The  LTE  EPC  model  is  displayed  in  Figure  43. 


Figure  43.  LTE  EPC  Model.  Source:  Scalable  Network 

Technologies  (2016). 


In  STK/QualNet,  simulation  errors  occur  when  running  applications  in  an  LTE 
user  equipment  (UE)  wireless  subnet  with  an  evolved  node  B  (eNB)  interface  and  UE 
interface  attached  to  nodes.  The  scenario  will  not  initialize  with  this  configuration.  If  all 
interfaces  are  changed  to  UEs  within  a  UE  wireless  subnet,  the  simulation  will  mn,  but 
LTE  packets  will  never  be  received. 

To  collect  data  on  the  LCS  as  a  router,  the  experiment  design  needed  to  be 
adjusted  due  to  these  limitations.  Rather  than  create  an  LTE  bubble,  an  802.11b  “network 
bubble”  was  modeled  into  the  scenario  using  parameters  for  devices  that  mimicked  those 
of  the  LTE  devices  described  in  Chapter  III.  The  eNB  antenna  was  mounted  on  the  upper 
levels  of  the  LCS  vice  the  flight  deck  as  in  the  previous  scenario. 

For  each  802.1  lb  UE,  a  separate  10  MHz  data  link  was  created  under  the  channel 
configuration  menu.  The  UEs  were  connected  to  the  LCS  eNB  antenna  through  these 
individual  links.  The  UE  links  to  eNB  each  formed  individual  subnets  so  that  the  devices 
could  not  communicate  with  one  another  unless  within  the  network  bubble.  A  test 
scenario  was  created  to  make  sure  the  network  bubble  functioned  properly;  in  the  test 
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scenario,  the  two  LCS  RHIBs  traveled  in  a  straight  line  away  from  the  vessel  while 
transmitting  a  CBR  application  to  one  another.  As  expected,  once  the  RHIBs  reached  the 
outer  edge  of  the  LCS  network  bubble  they  lost  all  connectivity  with  one  another  - 
despite  the  short  distance  separating  them. 

As  such,  the  redesign  of  the  scenario  was  in  line  with  the  original  concept  of 
testing  the  LCS’  performance  as  a  router.  The  Fire  Scout  was  modeled  with  a  channel  to 
support  the  camera  equipment  in  a  similar  manner. 

The  start  of  the  scenario  is  displayed  in  Figure  44,  where  the  Fire  Scout  is 
screening  the  area  ahead  of  the  LCS  and  sending  back  FTP  applications  through  the 
network  bubble.  The  effective  range  was  approximately  4.7  kilometers. 


Figure  44.  Scenario  2.  Fire  Scout  Sending  FTP  Application  to  LCS 
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The  LCS  and  Fire  Scout  transited  into  San  Francisco  Bay.  The  Fire  Scout 
approached  the  VOI  as  it  headed  due  north  on  the  opposite  side  of  Yerba  Buena  Island, 
sending  images  back  to  the  LCS.  Based  on  the  information,  the  LCS  changes  course  to 
launch  both  RHIBs  to  conduct  the  boarding  as  displayed  in  Figure  45. 

Figure  45.  Scenario  2.  RHIB  2  Approaching  the  VOI 
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Once  the  RHIBs  were  launched,  the  Fire  Scout  began  to  transmit  a  CBR 
application  of  56  bytes/second.  The  start  time  for  the  RHIB  2  application  was  4,680 
seconds  into  the  simulation,  sending  5,000  items  at  1-second  intervals.  The  start  time  for 
the  RHIB  1  application  was  5,280  seconds  into  the  simulation,  sending  the  same  number 
of  items.  The  total  scenario  time  was  10,800  seconds  (3  hours),  any  items  scheduled  to  be 
sent  beyond  the  end  time  were  truncated.  The  results  from  the  CBR  application  are 
displayed  in  Table  11. 


Table  11.  Scenario  2  Availability 


Application 

Originating 

Node 

Receiving 

Node 

Data  Tx 

Data  Rx 

Availability 

CBR 

8  (Fire 

Scout) 

5  (RHIB  2) 

5,000 

Unicast 

Segments 

5,000 

Unicast 

Segments 

100% 

CBR 

8  (Fire 

Scout) 

7  (LCS) 

10,799 

Unicast 

Segments 

10,799 

Unicast 

Segments 

100% 

CBR 

8  (Fire 

Scout) 

9  (RHIB  1) 

5,000 

Unicast 

Segments 

5,000 

Unicast 

Segments 

100% 

The  availability  was  high  in  this  scenario  due  to  the  fact  the  nodes  remained 
within  the  network  bubble  throughout  the  scenario  duration.  At  altitude,  the  Fire  Scout 
had  clear  LOS  to  the  LCS  eNB  antenna,  which  in  turn  routed  the  packets  to  the  RHIBs. 
The  3cm  dipole  antennas  on  the  handheld  devices  on  the  RHIBs  were  oriented  to  a  90- 
degree  elevation,  essentially  giving  them  a  vertical  radiating  pattern.  They  were  also 
placed  at  the  height  of  an  observer,  approximately  2  M  above  the  deck.  The  separate 
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channels  and  subnets  assigned  to  each  device  connecting  to  the  eNB  antenna  likely 
improved  performance  as  well. 

The  Fire  Scout  sent  the  FTP  applications  at  different  start  times  for  each  node. 
Each  file  size  was  1  MB,  with  a  maximum  of  20  files  sent.  The  start  time  was  1  second 
with  an  end  time  of  4,000  seconds  for  the  LCS,  5,280  seconds  with  and  end  time  of 
10,800  seconds  for  RHIB1,  and  4,680  seconds  with  an  end  time  of  10,800  seconds  for 
RHIB  2.  The  results  of  the  FTP  application  for  scenario  2  are  illustrated  in  Table  12. 


Table  12.  Scenario  2  FTP  Throughput 


Application 

Originating 

Node 

Receiving 

Node 

Data  Tx 

Data  Rx 

Throughput 

Tx 

Throughput 

Rx 

LTP 

8  (Lire 

Scout) 

5  (RHIB  2) 

20  MB 

20  MB 

1.85  KB/s 

1.85  KB/s 

LTP 

8  (Lire 

Scout) 

7  (LCS) 

20  MB 

20  MB 

1.85  KB/s 

1.85  KB/s 

LTP 

8  (Lire 

Scout) 

9  (RHIB  1) 

20  MB 

20  MB 

1.85  KB/s 

1.85  KB/s 

Lastly,  the  Network  IP  carried  load  demonstrated  the  Fire  Scout  is  generating  the 
most  traffic  with  the  LCS  receiving  some  of  it,  and  forwarding  packets  as  needed  to  the 
RHIBs.  The  Network  IP  carried  load  for  Scenario  2  is  illustrated  in  Table  13. 

Table  13.  Scenario  2  Network  IP  Carried  Load  (Bytes/Second) 


Node  ID 

5 

7 

8 

9 

Carried  Load 

818 

21,901 

29,168 

821 
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In  summary,  Scenario  2  demonstrated  the  LCS’s  ability  to  route  packets  to  nodes 
within  a  network  bubble.  The  4G  LTE  design  would  not  function  as  originally  planned, 
but  an  802.11b  network  bubble  sufficed.  The  nodes  in  the  scenario  experienced  high 
availability.  This  was  a  function  of  consistent  distances  of  nodes  from  the  LCS  while 
following  planned  routes — if  the  nodes  had  strayed  from  the  bubble,  there  would  have 
been  losses.  Also,  each  network  interface  connection  had  a  dedicated  subnet  and  10  MHz 
bandwidth  channel.  This  prevented  nodes  from  battling  for  resources.  Overall,  a 
functioning  LTE  model  would  have  been  ideal,  as  it  is  much  more  complex  in  its 
utilization  of  multiple-input-multiple-output  (MIMO)  antennas  on  UE  and  in  modeling 
the  way  in  which  the  core  network  (CN)  deals  with  the  assignment  of  resource  blocks. 
The  functionality  of  the  802.11b  network  bubble  cannot  be  directly  compared  to  LTE,  but 
it  did  demonstrate  the  effectiveness  of  some  of  the  Physical  Layer  properties  that  could 
be  designed  into  an  LTE  network  bubble  used  by  a  primary  node  LCS. 

C.  SCENARIO  3  DATA:  LCS  PERFORMING  AS  A  HUB 

Scenario  3  modeled  the  LCS  as  a  hub  broadcasting  data  packets  to  all  connected 
nodes  in  the  mesh  network.  In  this  scenario,  data  originates  from  the  Vernon,  Texas 
ground  station  as  well  as  LCS.  This  was  simulated  in  two  ways;  the  LCS  sending  a 
Constant  Bit  Rate  (CBR)  and  Vernon,  Texas  sending  application  files  to  all  nodes.  The 
overview  of  the  experiment  is  illustrated  in  Ligure  46  and  Table  14. 
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Figure  46.  Scenario  3  Overview.  Source:  Scalable  Network 

Technologies  (2016). 
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Table  14.  Scenario  3  Nodes 


QualNet 

Node  ID 

STK  Platform 

T  ype/Model/Description 

STK 

Antenna/Sensor 

QualNet  PHY 

Model 

QualNet 

Subnet 

5 

Ship/CG  3D 

Model/Ticonderoga  Class 
CG 

Rectangular 

Pattern 

802.11a/g 

192.168.1.0 

6 

Ship/DDG  3D 
Model/Arleigh  Burke 

Class  DDG 

Rectangular 

Pattern 

802.11a/g 

192.168.1.0 

7 

Ship/LCS  3D 

Rectangular 

802.11a/g, 

192.168.1.0, 

Model/Freedom  Class 

LCS 

Pattern, 

Parabolic,  Fixed 
Target  Sensor 

Satellite-RSV 

190.0.3.0 

23 

Place/Facility /03b 

Ground  Station 

Parabolic 

Satellite-RSV 

190.0.2.0 

11 

Satellite/M003/03b 

MEO 

Parabolic,  Fixed 
Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

15 

Satellite/M007/03b 

MEO 

Parabolic,  Fixed 
Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

17 

Satellite/M009/03b 

MEO 

Parabolic,  Fixed 
Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

19 

Satellite/MOl  l/03b 

MEO 

Parabolic,  Fixed 
Target  Sensor 

Satellite-RSV 

190.0.2.0, 

190.0.3.0 

8 

Ship/Rubber  Boat  3D 
Model/CG  RHIB 

Isotropic 

802.11a/g 

192.168.1.0 

22 

Ship/Rubber  Boat  3D 
Model/DDG  RHIB 

Isotropic 

802.11a/g 

192.168.1.0 
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In  addition  to  the  nodes  used  in  Scenario  1,  the  cruiser  and  destroyer  each 
launched  a  RHIB  to  conduct  picket  boat  operations.  The  scenario  run  time  was  6  hours 
for  the  same  reason  as  scenario  1.  A  bird’s  eye  view  of  node  placement  is  displayed  in 
Figure  47. 


Figure  47.  Scenario  3  Nodes  in  San  Francisco  Bay 
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The  network  design  of  the  scenario  consisted  of  the  subnets  in  Table  14  and 
manual  assignment  of  a  broadcast  IP  address  to  the  DDG  RHIB.  The  Wave  Relay  subnet 
mask  was  255.255.255.224,  and  the  broadcast  IP  address  of  the  RHIB  was  192.168.1.31. 
The  results  of  the  simulation  were  the  same  regardless  of  which  node  in  the  Wave  Relay 
subnet  was  assigned  the  broadcast  address.  The  CBR  application  was  sent  from  the  LCS 
to  the  DDG  RHIB,  which  broadcast  the  application  to  all  nodes  in  the  subnet.  The  results 
are  illustrated  in  Table  15. 


Table  15.  Scenario  3  Availability 


Application 

Originating 

Node 

Receiving 

Node 

Data  Tx 

Data  Rx 

Availability 

CBR 

7  (LCS) 

5  (CG) 

21,599  UDP 

Broadcast 

Segments 

9,742  UDP 

Broadcast 

Segments 

45.1% 

CBR 

7  (LCS) 

6  (DDG) 

21,599  UDP 

Broadcast 

Segments 

13,416  UDP 

Broadcast 

Segments 

62.1% 

CBR 

7  (LCS) 

8  (CG 

RHIB) 

21,599  UDP 

Broadcast 

Segments 

2,886  UDP 

Broadcast 

Segments 

13.4% 

CBR 

7  (LCS) 

22(DDG 

RHIB) 

21,599  UDP 

Broadcast 

Segments 

445  UDP 

Broadcast 

Segments 

2.06% 

Reception  of  broadcast  packets  was  low  on  the  RHIBs;  this  can  be  attributed  to 
the  fact  that  the  RHIBs  were  modeled  with  2.4  GHz  isotropic  antennas,  giving  them  a 
lower  effective  range — approximately  1.4  KM  -  in  the  mesh  when  compared  to  sector 
array  antennas.  The  broadcast  packets  do  not  hop  across  other  nodes  to  create  more 

99 


efficient  routes;  they  simply  radiate  from  the  LCS  and  are  received  by  all  nodes  in  range. 
The  RHIBs  remained  in  relatively  static  picket  positions  at  the  edge  of  the  ships’ 
operational  boxes,  so  when  the  LCS  moved  from  one  end  of  its  box  to  the  other,  there 
was  no  reception.  As  in  scenario  1,  increased  distance  induced  high  availability  losses. 

Next,  the  same  CBR  application  was  sent  from  the  Vernon  ground  station  to  the 
RHIB.  The  application  did  not  broadcast,  however.  The  broadcast  IP  address  was 
reassigned  to  the  Wave  Relay  device  on  the  LCS,  but  the  results  were  the  same.  This  was 
simply  because  the  originating  interface  and  the  broadcast  interface  were  on  different 
subnets. 

To  work  around  the  issue,  a  multicast  domain  was  established  to  send  packets 
from  Vernon  directly  to  the  LCS  Wave  Relay  interface  with  the  broadcast  address,  but 
this  did  not  solve  the  issue.  It  was  assumed  the  application  would  not  broadcast  due  to 
different  broadcast  domains  between  the  two  subnets,  and  a  workaround  was  not  found. 

As  described  in  Scenario  1,  the  super  application  did  not  function  in 
STK/QualNet.  This  application  would  have  been  very  helpful  in  testing  UDP  broadcast. 
Due  to  the  limitations,  an  FTP  experiment  was  designed  to  test  throughput.  FTP  uses 
TCP  at  the  Transport  Layer  and  therefore  cannot  broadcast  on  a  subnet  like  UDP. 
However,  to  complete  the  experiment  using  the  LCS  as  a  hub  or  node  to  distribute  data,  it 
was  tailored  to  suit  the  need. 

Instead  of  the  LCS  broadcasting  a  single  application,  the  Vernon  ground  station 
simultaneously  transmitted  an  FTP  application  to  each  node  —  this  was  more  intensive  on 
satellite  bandwidth.  The  FTP  application  was  configured  to  send  a  maximum  of  20  items 
with  a  file  size  of  2  MB  each  at  random  intervals  throughout  the  scenario  to  every  node 
(excluding  the  LCS).  The  results  are  displayed  in  Table  16. 
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Table  16.  Scenario  3  FTP  Throughput 


Application 

Originating 

Node 

Receiving 

Node 

Data 

Tx 

Data 

Rx 

Throughp 

ut  Tx 

Throughp 

ut  Rx 

FTP 

23  (Vernon) 

5  (CG) 

40  MB 

40MB 

1.85  KB/s 

1.85  KB/s 

FTP 

23  (Vernon) 

6  (DDG) 

40  MB 

2  MB 

1.85  KB/s 

.093KB/S 

FTP 

23  (Vernon) 

8  (CG 

RHIB) 

0  MB 

0  MB 

- 

- 

FTP 

23  (Vernon) 

22  (DDG 

RHIB) 

8  MB 

2  MB 

,37KB/s 

.093KB/S 

Due  to  the  randomization  in  the  number  of  files  to  be  sent,  the  simulation  did  not 
send  anything  to  node  8.  The  CG  experienced  the  highest  throughput  despite  having 
lower  availability  in  the  CBR  experiment.  The  lower  availability  may  have  been  due  to 
longer  periods  of  stable  connectivity  vice  data  links  breaking  and  reforming  with  the 
DDG.  With  FTP,  the  TCP/IP  protocol  used  at  the  Transport  Layer  must  handshake  and 
confirm  delivery  of  packets.  If  the  link  breaks,  this  protocol  must  reestablish  the  three- 
way  connection.  Compared  to  the  CBR  application,  which  uses  a  connectionless 
approach  by  streaming  UDP  segments,  this  makes  data  transfer  more  difficult  under  less 
than  ideal  conditions.  There  are  advantages  and  disadvantages  to  each,  depending  on  the 
overall  purpose  of  the  mission  (streaming  video,  sending  image  files). 

The  Network  IP  carried  load  for  scenario  3  is  displayed  in  Table  17. 


Table  17.  Scenario  3  Network  IP  Carried  Load  (Bytes/Second) 


Node 

ID 

5 

6 

7 

8 

11 

15 

17 

19 

22 

23 

Carried 

Load 

141 

64 

4,729 

.09 

2.7 

1.9 

2.31 

4733 

217 

4415 
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From  this  data,  the  nodes  with  the  largest  amount  of  network  traffic  are  the  LCS, 
the  ground  station,  and  03b  satellite  M011.  MO  11  is  the  satellite  that  has  access  to  the 
LCS  Ka-band  terminal  at  initialization  of  the  scenario.  It  appears  most  files  sent  through 
the  FTP  application  were  delivered  during  this  access  window.  The  CG,  receiving  the 
most  files,  had  an  FTP  session  start  time  of  1  second  which  ended  at  724  seconds.  During 
this  time,  the  CG  had  stable  connectivity  with  the  LCS  through  the  Wave  Relay  subnet 
due  to  its  proximity.  The  DDG,  receiving  the  least  number  of  files  sent,  started  an  FTP 
session  at  1  second  and  ended  at  7,572  seconds.  TCP  packets  were  received  only  during 
the  first  few  minutes.  The  DDG  experienced  lower  connectivity  due  to  its  increasing 
range  from  the  LCS  as  the  scenario  progressed.  At  the  outset  of  the  Scenario,  the  DDG 
and  LCS  were  close  to  one  another,  but  they  immediately  went  off  in  different  directions, 
with  the  LCS  on  a  heading  closing  the  distance  to  the  CG.  This  maneuver  once  again 
demonstrated  the  effect  of  distance  and  mobility  of  nodes  on  availability  and  throughput. 

A  summary  of  findings  in  Scenario  3  is  as  follows:  broadcasting  packets  from  the 
LCS  as  a  primary  node  requires  the  other  nodes  to  be  within  proximity  to  be  of  use. 
Broadcast  data  packets  will  not  hop  across  nodes  in  the  mesh  to  reach  their  destination.  A 
method  to  get  around  broadcast  domains  between  the  03b  and  Wave  Relay  subnets 
would  have  improved  data  collection  during  the  scenario.  Using  the  FTP  application,  the 
LCS  could  distribute  files  2  MB  in  size  originating  from  the  Vernon  ground  station  to 
nodes  within  the  mesh.  Performance  varied  based  on  mobility,  distance,  and  whether 
antennas  were  sector  array  or  isotropic. 
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D. 


SCENARIO  4  DATA:  LCS  PERFORMING  AS  A  BRIDGE 


Scenario  4  consisted  of  unmanned  systems  sending  information  through  LOS 
point-to-point  wireless  links  and  mesh  to  their  respective  controlling  platforms,  and  in 
turn  linking  this  information  to  one  another  through  a  central  LCS  performing  as  a 
network  bridge.  This  is  illustrated  in  Figure  48  and  Table  18. 


Figure  48.  Scenario  4  Overview.  Source:  Scalable  Network 

Technologies  (2016). 
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Table  18.  Scenario  4  Nodes 


QualNet 

Node  ID 

STK  Platform  Type 

STK 

Antenna/Sensor 

QualNet  PHY 

Model 

QualNet 

Subnet 

7 

Ship/LCS  3D 

Model/Freedom  Class 

LCS  functioning  as 

network  bridge 

Uniform 

Aperture 

Rectangular 

Abstract 

190.0.6.0, 

190.0.7.0 

5 

Ship/LCS  3D 

Model/Freedom  Class 

LCS  with  RQ-8A 

control  station 

Uniform 

Aperture 

Circular, 

Uniform 

Aperture 

Rectangular 

Abstract 

190.0.4.0, 

190.0.5.0, 

190.0.6.0 

6 

Ship/LCS  3D 

Model/Freedom  Class 

LCS  with  USV  control 

station 

Isotropic, 

Uniform 

Aperture 

Rectangular 

Abstract,  802.11b 

190.0.9.0, 

190.0.7.0 

9 

Aircraft/RQ-8A  3D 

Model/Fire  Scout 

Uniform 

Aperture 

Circular 

Abstract 

190.0.4.0 

10 

Aircraft/RQ-8A  3D 

Model/Fire  Scout 

Uniform 

Aperture 

Circular 

Abstract 

190.0.5.0 

13 

Ship/HSMST  3D  Model 

Isotropic 

802.11b 

190.0.9.0 

14 

Ship/HSMST  3D  Model 

Isotropic 

802.11b 

190.0.9.0 
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The  total  length  of  the  Scenario  was  3  hours;  it  initiated  with  all  nodes  near  one 
another  and  on  a  course  approaching  the  mouth  of  San  Francisco  Bay.  The  speed  of  the 
nodes  remained  relatively  constant,  approximately  10  knots  unless  it  was  necessary  for  a 
node  to  increase  speed  to  catch  up  with  the  formation  following  a  turn.  The  2D  overview 
in  Figure  49  displays  the  nodes  and  routes  taken  during  the  first  leg  of  the  scenario. 


Figure  49.  Scenario  4  Nodes  and  Routes 


CBR  applications  were  established  to  test  availability  as  prescribed  in  the  research 
design.  The  characteristics  of  the  applications  and  associated  availability  are  illustrated  in 
Table  19. 
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Table  19.  Scenario  4  Availability 


Application 

Originating 

Node 

Receiving 

Node 

Data  Tx 

Data  Rx 

Availability 

CBR 

9  (Fire  Scout 

1) 

6 

(LCS 

Controlling 

USVs) 

10,799 

Unicast 

Segments 

10,799 

Unicast 

Segments 

100% 

CBR 

10  (Fire 

Scout  2) 

6 

(LCS 

Controlling 

USVs) 

10,799 

Unicast 

Segments 

10,799 

Unicast 

Segments 

100% 

CBR 

13  (Sea  Fox 

1) 

5 

(LCS 

Controlling 

Fire  Scouts) 

10,799 

Unicast 

Segments 

6,810 

Unicast 

Segments 

63% 

CBR 

14  (Sea  Fox 

2) 

5 

(LCS 

Controlling 

Fire  Scouts) 

10,799 

Unicast 

Segments 

6,810 

Unicast 

Segments 

63% 

The  availability  of  the  Fire  Scouts  to  the  LCS  USV  controller  was  high  for  many 
reasons:  they  were  airborne,  their  directional  antennas  had  higher  gains,  and  the  TCDL 
link  was  established  as  point-to-point  microwave  links  in  STK/QualNet.  The  point-to- 
point  abstract  links  in  QualNet  typically  enable  full  access  as  long  there  is  LOS  between 
transmitting  and  receiving  interfaces.  The  same  can  be  said  of  the  Tsunami  wireless 
point-to-point  links  connecting  the  LCS  platforms  to  one  another.  The  Sea  Fox  US  Vs, 
connected  to  their  corresponding  LCS  with  2.4  GHz  isotropic  antennas,  experienced 
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degraded  availability  for  the  same  reasons  as  outlined  in  previous  scenarios.  As  with 
previous  experiments,  the  FTP  application  was  set  to  start  at  0  seconds  and  transmit  files 
of  2  MB  in  size  until  the  scenario  ended.  The  point-to-point  links  worked  well  for  the 
same  reasons  as  described  in  the  CBR  section.  Scenario  4  FTP  throughput  is  displayed  in 
Table  20  and  the  carried  load  over  Network  IP  is  displayed  in  Table  21. 


Table  20.  Scenario  4  FTP  Throughput 


Application 

Originating 

Node 

Receiving 

Node 

Data  Tx 

Data  Rx 

Throughput 

Tx 

Throughput 

Rx 

FTP 

9  (Fire 

Scout  1) 

6  (LCS 

Controllin 

g  USVs) 

458  MB 

456  MB 

42.4  KB/s 

42.2  KB/s 

FTP 

10  (Fire 

Scout  2) 

6  (LCS 

Controllin 

g  USVs) 

460  MB 

456  MB 

42.5  KB/s 

42.2  KB/s 

FTP 

13  (Sea 

Fox  1) 

5  (LCS 

Controllin 

g  Fire 

Scouts) 

42  MB 

40  MB 

3.9  KB/s 

3.7  KB/s 

FTP 

14  (Sea 

Fox  2) 

5  (LCS 

Controllin 

g  Fire 

Scouts) 

42  MB 

40  MB 

3.9  KB/s 

3.7  KB/s 

Table  21.  Scenario  4  Network  IP  carried  load  (bytes/second) 


Node  ID 

5 

6 

7 

9 

10 

13 

14 

Carried 

Load 

1,267,815 

199,647 

1,374,030 

587,992 

587,905 

54,049 

53,347 
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Node  7,  the  LCS  performing  as  the  major  node,  carried  approximately  1.37  MB/s 
(Table  21)  throughout  the  duration  of  the  scenario.  This  factors  into  the  IP  traffic 
traversing  the  wireless  network  bridge  from  both  LCS  nodes  controlling  the  unmanned 
systems. 

In  summary,  Scenario  4  showed  that  point-to-point  links  creating  a  network 
bridge  are  effective  at  relatively  close  ranges  with  the  LCS  acting  as  a  major  node.  Also, 
the  nodes  moved  along  predetermined  routes  to  support  this  connectivity,  and  that 
improved  availability. 

E.  EXATA  5.3  CONCEPTUAL  EXPERIMENT 

The  EXata  application  functioned  as  anticipated  in  many  respects.  The  QualNet 
configuration  file  created  from  the  STK/QualNet  interface  maintained  latitude/longitude 
positional  data  and  network  properties  when  loaded  into  EXata.  However,  the  positional 
data  was  only  inherited  for  the  nodes’  starting  points — mobility  was  not.  This  was 
overcome  with  relative  ease  by  creating  waypoints  within  the  EXata  palette.  Also,  when 
emulation  is  initiated,  nodes  can  be  placed  or  removed  to  observe  the  effect  on  network 
performance.  Figure  50  illustrates  that  positional  data  from  San  Francisco  Bay  was 
inherited  from  the  STK/QualNet  scenarios  for  the  LCS. 


Figure  50.  LCS  (Node  7)  Positional  Data.  Source:  Scalable  Network 

Technologies  (2016). 
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Two  aspects  of  the  experiment  were  not  accomplished  due  to  technical 
challenges.  First,  the  SolarWinds  application  was  not  able  to  install  on  IT140321  due  to 
lack  of  administrative  privileges.  The  application  required  the  installation  of  MySQL 
Express  to  store  and  maintain  a  network  management  database,  which  would  not  install 
on  NPS  machines  even  with  local  administrative  privileges — additional  administrative 
rights  were  required  and  not  available.  Also,  the  machine  running  EXata  was  not  able  to 
identify  IT140321  as  an  operational  host.  This,  however,  was  not  a  major  issue  as  other 
machines  in  the  CENETIX  lab,  detected  on  the  network,  can  use  the  EXata  Connection 
Manager  and  function  as  operational  hosts. 

The  trial  version  of  EXata  5.3  was  operable  for  less  than  two  weeks.  If  a  fully 
licensed  copy  was  available,  more  experimentation  could  have  been  performed,  and  the 
issues  resolved.  Hence,  to  design  an  experiment  with  observable  network  management 
metrics,  a  fully  licensed  copy  of  the  software  is  needed. 
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V.  FINDINGS  AND  FUTURE  RESEARCH 


Once  a  year,  Navy  Fleet  Week  provides  a  window  for  a  variety  of  Navy  and  Coast 
Guard  platforms  to  conduct  C4I  experimentation  in  San  Francisco  Bay  with  the 
CENETIX  TNT.  This  exercise  provides  an  opportunity  for  system  stakeholders  to  test  the 
use  of  fly-away  kits  and  mobile  communications  equipment  as  well  as  other  C4I  concepts 
on  a  variety  of  platforms,  including  the  LCS.  Other  venues  for  Fleet  experimentation 
would  also  serve  this  purpose.  The  simulated  scenarios  using  only  waterborne  assets 
would  not  be  exceedingly  difficult  to  be  carried  out  as  field  experiments. 

The  simulation  results  of  our  research  demonstrated  wireless  network  capabilities 
by  equipping  the  LCS  with  commercially  available  wireless  mesh  and  MANET 
equipment,  as  well  as  integrating  levels  of  military  equipment.  One  of  the  initial  findings 
that  was,  perhaps,  intuitive,  is  that  distance  and  mobility  of  nodes  played  a  large  part  in 
the  effectiveness  of  the  LCS  as  a  major  node.  Units  operating  in  a  mesh  network  created 
by  the  LCS  must  remain  constantly  aware  of  the  effective  ranges  of  the  equipment  in  use 
if  they  hope  to  take  full  advantage  of  it. 

A  challenge  encountered  in  this  research  was  acquiring  software  educational 
license  agreements  for  versions  of  STK  and  QualNet  that  were  compatible  with  one 
another.  The  newest  version  of  QualNet  at  the  time  of  this  thesis  (QualNet  7.4)  was  only 
compatible  with  the  latest  version  of  STK  (STK  11).  Only  the  32-bit  version  of  QualNet 
(QualNet  version  7.3)  was  compatible  with  the  STK  version  available  at  NPS  (STK 
10.1.3)  during  the  period  of  research.  QualNet  software  agreements  are  node-locked, 
meaning  that  only  individual  Naval  Postgraduate  School  student  researchers  can  access 
the  most  up-to-date  versions  of  the  software.  The  Scalable  Networks  QualNet  agreements 
had  to  be  brokered  between  student  researchers,  a  faculty  member,  and  the  software 
companies. 

The  learning  curve  for  self-taught  skills  in  creating  STK/QualNet  scenarios  was 
steep — many  scenarios  needed  to  be  created  to  gain  an  understanding  of  the  intricate 
relationship  between  the  STK/QualNet  interfaces.  STK  and  QualNet  maintain  a  plethora 
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of  documentation  describing  each  as  a  standalone  program,  but  there  is  little 
documentation  to  tie  the  two  together.  Hence,  many  of  the  limitations  and 
incompatibilities  of  STK/QualNet  had  to  be  discovered  through  trial  and  error. 

The  designed  STK/QualNet  scenarios  successfully  ran  and  collected  data,  but  the 
interaction  between  STK  objects  and  QualNet  interfaces  often  did  not  occur  as  expected. 
For  example,  QualNet  interfaces  could  link  to  STK  antenna  objects  and  sensors,  but  not 
transmitters  and  receivers.  STK  antenna  objects  linked  with  QualNet  interfaces  could  be 
assigned  as  parent  objects  of  STK  transmitters  and  receivers,  but  this  had  no  impact  on 
simulation  runs  even  when  extreme  setting  changes  were  made.  This  configuration  was 
tested  by  performing  the  same  simulation  runs  with  and  without  the  transmitter  and 
receiver  objects  attached  to  antennas.  The  detriment  of  this  was  that  antennas  without 
attached  transmitters  and  receivers  had  less  experimental  capability;  properties  such  as 
polarization,  additional  gains,  and  data  throughput  based  on  propagation  models  could 
not  be  customized. 

The  simulation  model  was  not  able  to  fully  test  throughput  limitations  of  the 
mesh.  The  Super  Application  for  doing  this  would  not  run  in  the  STK/QualNet  interface 
even  when  configured  with  recommended  parameters.  The  best  throughput  measure  that 
could  be  achieved  was  sending  large  files  with  the  FTP  application  in  the  scenarios. 
QualNet  trace  files,  generated  upon  completion  of  a  simulation  run,  were  recorded  as 
taking  up  anywhere  from  2  GB  to  8  GB  on  the  local  hard  disk  when  running  this  type  of 
iteration.  These  files  needed  to  be  periodically  removed  to  free  up  system  resources. 
Hence,  the  observation  was  that  testing  throughput  caused  issues  with  resources  on  the 
local  machine  running  the  simulation.  It  is  uncertain  whether  the  Super  Application,  had 
it  been  able  to  run,  would  have  overburdened  system  resources  to  the  same  extent  or 
greater. 

The  EXata  5.3  emulation  testbed  showed  promising  capabilities.  However,  the 
short  period  it  was  made  available  was  not  enough  to  set  up  complex  network 
management  experiments  with  the  LCS. 
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Additional  follow-on  research  may  include: 

•  Modeling  LCS  ADNS  networks  connected  to  commercial  satellite 
providers  to  test  throughput  limitations 

•  Effectiveness  of  the  LCS  as  a  network  manager  in  a  mesh  network  using 
an  emulation  testbed 

•  Modeling  a  4G  LTE  EPC  network  on  the  LCS  if  compatible  with 
STK/QualNet  in  future  versions 

•  Field  experimentation  with  vessels  participating  in  fleet  week  using  Wave 
Relay  devices  and  fly-away  kits  for  other  wireless  networking  experiments 

•  Modeling  optimized  formation  and  placement  of  nodes  for  availability 
around  an  LCS  performing  as  a  major  node  in  a  mesh  network 

•  Feasibility  of  an  LCS  C4I  mission  package  utilizing  mesh  and  high- 
bandwidth  satellite  technology 

•  Simulations  evaluating  the  LCS  with  other  tactical  network 
communication  devices 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


This  thesis  research  answered  the  question,  “How  well  the  LCS  platform  can 
perform  as  a  Wireless  Mesh  Network  node  in  a  littoral  environment”  with  Unmanned 
Surface  Vessels  (USV)  and  other  nodes.  This  was  accomplished  by  modeling  the 
platform  as  an  Internet  Gateway,  router,  hub,  and  network  bridge  in  simulation.  The 
results  demonstrated  favorable  and  unfavorable  capabilities  depending  on  equipment 
used  and  movement  of  nodes. 

The  research  partially  answered  the  question  of  how  network  management 
software  can  assist  in  identifying  the  optimal  role  of  the  LCS  platform  in  a  WMN,  and 
presented  a  baseline  model  to  be  used  with  EXata  5.3  emulation  software  to  test  network 
management  capabilities  of  the  LCS.  It  is  recommended  that  NPS  acquire  rights  to  this 
software,  or  a  comparable  tool,  to  establish  an  emulation  testbed  for  projects  on  network 
management  using  the  LCS. 

A  recommendation  for  improving  network  simulation  research  opportunities  for 
NPS  students  is  for  the  campus  to  aquire  server-license  agreements  for  STK/QualNet. 
This  would  smooth  out  logistical  issues  and  allow  for  students  to  experiment  without  the 
need  for  node-locked  license  agreements.  Lurthermore,  students  in  the  Network 
Operations  and  Technology  (NWOT)  curriculum  are  not  required  to  take  courses  giving 
them  hands-on  experience  with  these  simulation  programs.  QualNet  and  STK  are  capable 
of  performing  simulations  with  a  substantial  number  of  DOD  platforms  and  associated 
communications  equipment.  The  in-depth  analysis  of  networking  protocols  and  DOD 
network  architecture  that  this  software  can  provide  closely  parallels  learning  objectives  of 
the  NWOT  curriculum.  It  is  further  recommended  that  a  required  course  be  offered  that 
instructs  NWOT  students  the  basics  of  using  network  modeling  software  as  it  pertains  to 
DOD  systems,  which  may  in  turn  garner  interest  in  research  like  that  conducted  in  this 
thesis. 

The  STK/QualNet  simulation  of  the  LCS  performing  as  a  major  node  in  a 
wireless  mesh  network — under  the  vignette  of  a  multi-vessel  San  Lrancisco  Lleet  Week 
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C4ISR  field  experiment — demonstrated  the  platform’s  potential  to  execute  network¬ 
centric  warfare  roles.  Bearing  all  modeling  constraints  of  STK/QualNet  in  mind,  the  LCS 
proved  capable  of  fulfilling  networking  roles  as  an  Internet  gateway,  router,  hub,  and 
bridge  to  varying  degrees  of  performance  and  reliability  in  a  mesh.  The  research 
demonstrated  a  macroscopic  view  of  the  effectiveness  of  communications  links — mainly 
those  offered  by  tactical  wireless  devices  and  satellite  equipment  commercially 
available — connecting  manned  and  unmanned  nodes  in  a  mesh  network  to  a  theoretical 
core  tactical  network  on  the  LCS.  The  simulation  did  not  model  internal  network 
interactions  between  LCS  mission  modules  and  ADNS  combat  systems  architecture.  The 
intricacies  of  LCS  internal  networks  may  be  well  be  beyond  the  scope  and  capabilities  of 
the  developed  model.  As  such,  a  recommendation  is  to  conduct  Fleet  field  experiments 
with  tactical  wireless  networking  equipment  connected  to  an  ADNS  network  on  an  LCS 
and  other  nodes.  Furthermore,  it  would  be  useful  to  model  any  tactical  wireless  field 
experiments  beforehand  to  observe  effective  ranges  of  proposed  equipment  and 
configuration,  as  well  as  the  impact  of  node  mobility  on  performance.  The  model 
developed  for  this  research  offers  reusability  for  various  equipment  and  networking 
parameters  that  can  be  continuously  adjusted  or  improved  to  serve  the  needs  of  Fleet 
experiment  designers.  The  vignette  of  the  LCS  performing  as  a  major  node  by  modeling 
it  as  an  Internet  gateway,  router,  hub,  and  bridge  is  merely  a  springboard  for  future 
network-centric  warfare  research  and  experimentation. 

The  CONOPS  for  LCS  is  continuously  undergoing  redefinition  and 
improvements.  Only  through  further  simulation  and  field  experimentation  can  the  true 
network  warfare  and  Distributed  Lethality  potential  of  this  platform  be  evaluated.  As 
such,  it  is  fitting  to  conclude  with  a  quote  from  Mr.  Work. 

“Future  variants  of  the  LCS  may  evolve  in  ways  not  now  anticipated  or  foreseen, 
just  as  happened  with  torpedo  boats.  The  only  thing  standing  in  the  way  of  success  for 
LCS  would  be  a  lack  of  imagination  and  hard  work.”  (Work,  2014) 
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APPENDIX  A.  036  OPERATIONS  AND  DATASHEETS 


03b's  Communications  Concept 

♦3b 

Networks 

f<btr  3f*td.  Kttck 

Steerable  Ka-band  spot  beams 
Seamless  handover  between  satellites 
Bent-pipe  connecting  gateways  with 
customers  for  internet  access 
2  beams  per  satellite  for  gateways 
10  beams  per  satellite  for  customers 
Customers  use: 

•  medium/large  ES  only  for  high 
capacity  fixed  links 

•  Medium/small  ES  for  mobile 
applications 

Beam  coverage:  ~700  km  diameter 
Channel  bandwidth:  216  MHz 
Coverage  ~45  N°  N/S  latitude 


Source:  Barnett  (2013) 
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7.3  Meter  Ka-Band  Antenna 

Broadband  Gateway  Earth  Station 


The  7.3  meter  Ka-band  gateway  is 
an  integral  part  of  the  broadband 
system  delivering  high-speed  WiFi 
connections  for  residential,  commercial 
and  government  services.  The  antenna 
is  efficiently  designed  to  receive  and 
transmit  data  from  high  capacity  satellites 
to  make  full  use  of  their  high  data  rate 
capabilities. 


Site  Information 

Venue  Name 
Latitude  (NAD  83) 
Longitude  (NAD  83) 
Climate  Zone 
Rain  Zone 

Ground  Elevation  (AMSL) 


VERNON,  TX 

34°  13' 4.7"  N 
99°  23'  46.5"  W 
A 
2 

390.47  m/ 1281.1  ft 


Link  Information 

Satellite  Type 

Mode 

Modulation 

Minimum  Elevation  Angle 
Azimuth  Range 
Antenna  Centerline  (AGL) 


Low  Earth  Orbit 

TR  -  Transmit-Receive 

Digital 

3.0° 

0.0°  to  360° 

3.66  m /12.0  ft 


Antenna  Information 

Receive  -  FCC32 

Transmit  -  FCC32 

Manufacturer 

ViaSat 

ViaSat 

Model 

8073 

8073 

Gain  /  Diameter 

61.2  dBi  /  7.3  m 

65.0  dBi /7.3  m 

3-dB  /  15-dB  Beamwidth 

0.02°/ 0.04° 

0.01°/  0.02° 

Max  Available  RF  Power 

(dBW/4  kHz) 

15.7 

(dBW/MHz) 

397 

Maximum  EIRP 

(dBW/4  kHz) 

80.7 

(dBW/MHz) 

104.7 

Interference  Objectives: 

Long  Term 

-156.0  dBW/MHz  20% 

-151.0  dBW/4  kHz  20% 

Short  Term 

-146.0  dBW/MHz  0.01% 

-128.0  dBW/4  kHz  0.0025% 

Frequency  Information 

Receive  18.0  GHz 

Transmit  28.0  GHz 

Source:  VIAsat  (2012) 
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03  b  Maritime 


Technical  Specifications 

Antenna  Type:  Dual  offset  Gregorian 

Antenna  size:  1.15m  (45") 

Radome  Size:  D:  1.55m  (61") 

H:  1.69m  (67") 

ADE  Weight  (Exc  BUC):  185Kg  (408  lb) 

Configuration:  A  quadruple-axis  polarization-over-  elevation-over-tilt- 

over-azimuth 

Range  of  Dynamic  Motion:  Full  hemispherical  coverage,  down  to  satellite  elevation 

view  angle  as  low  as  10°  at  all  sea  conditions.  With  no 
"keyholes"  at  zenith  or  horizon 

Range  of  Mechanical  Pedestal  Axes: 

Azimuth:  Continuous 
Elevation:  -30“  to  +120° 

Cross  Elevation:  -75°  to  +75° 

Ship  Gyro  Interface:  NMEA  0183,  Step  by  Step,  Synchro 

Operating  Frequency  -  (Range  via  2  selectable  bands): 

Rx  17.8  GHZ  to  19.3  GHz 

Tx  27.6  GHz  to  29.1  GHZ 

System  G/T  (dB/°K,  Typical  includes  all  losses): 

>19dB/°K  (5)  mid-range  at  20°  Elevation 

Source:  03b  Networks  (2013) 


119 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


120 


APPENDIX  B.  4G  LTE  SPECIFICATIONS 


Model 

ZDAQJ700-6 

ZDAQJ700-8 

ZDAQJ700-10 

Frequency  Range 

698-755  MHz  I 

698-755  MHz 

698-755  MHz 

Gain 

6dBi 

8dBi 

lOdBi 

Polarization 

Vertical 

Vertical 

Vertical 

Horizontal  Beam 

[width  _ 

B60  ° 

360° 

360° 

Vertical  Beam  Width  30  ° 

25° 

16° 

VSWR 

<1.5 

<1.5 

<1.5 

Input  Impedance 

50  ohm 

50  ohm 

50  ohm 

Input  Maximum 
Power 

200  W 

200  W 

200  W 

Lightning  Protection  DC  Ground 

DC  Ground 

DC  Ground 

Connector 

N  female  or 

1 

customized 

N  female  or 
customized 

N  female  or 
customized 

Size 

39.37in.(1000  mm)61in.(1550  mm) 

110in.(2800  mm) 

Radiating  Electrical 
Material 

Cu  Ag 

Cu  Ag 

Cu  Ag 

Radome  Material 

Fiberglass 

Fiberglass 

Fiberglass 

Operating 

Temperature 

\40‘  Cto  85°  C 
(-40°  F  to  185° 

F) 

-40°  Cto 85°  C 
(-40°  F  to  185°  F) 

-40°  Cto 85°  C 
(-40°  F  to  185°  F) 

Diameter  of 
Installation  Pole 

1.2-2.3in.  (30-60 
mm)  _ 

1.2-2.3in.  (30-60  mm)1.2-2.3in.  (30-60  mm) 

Weight 

3.3  Lbs  (1.5  Kg) 

4.4  Lbs  (2  Kg) 

9.4  Lbs  (3.5  Kg) 

Source:  ZDA  Communications  (2014). 
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APPENDIX  C.  TSUNAMI  QB-10100  SERIES  NETWORK  BRIDGE 


Specifications:  Tsunami  '  QB-10100  Series 


PftOOUCT  MOOC IS  MAT  NUMBERS 

902-00771  OB-WTOO-CNK-WD 
002-00775  QQ-W150-LNK-WD 
002-00780  08-101504.  XL  -WO 

mttafaccs 


OB-IOWO-LNK 
OQ-T015O-LNK 
08-10150-1  Kl 


Tsunami*  OB  W100  Link,  vngle  rec*o.  866  Mbps.  MiMO  2*2.  Typ*-N  Connector* 
Tsunami*  OB  10150  Link,  single  radio.  866  Mbps.  MiMO  2*2. 22  dOi  integrated 
Tsunami*  08  10150  Link  loog^ange.  single  radio.  86G  Mbps,  MIMO  2*7.  78  dRi 


90200769  QB-IOIOO-LNK-US 
90200773  QQ-1015O-LNK-US 
90200779  06-101 50-LKL-4JS 


WIRED  ETHERNET  Two  auto  MDl  X  RJ45  tOIOO-IOOOMhp'.  Ethernet  (Pod  #1  with  Pof  in  A  Data.  Port  »2  with  PoE  out  6  Data) 

WIRELESS  PROTOCOL  WORP*  (Wireless  Outdoes  Router  Protocot) 

RADIO  A  TX  SPECS 


MIMO 

MODULATION 
FREQUENCY 
CHANNEL  S*2£ 

DATA  RATE 
TXPOWFR 
TX  POWER  CONTROL 


7x2-2 

OT DM  With  BPS*.  OPSK.  QAM  16,  QAM 64.  QAM2S6 
5150  -  5  975  GHz  (Subject  to  Country  Regulations) 

80  MHz.  40  MHz  and  20  MHz 

MC5  0  to  9  with  Dynamic  Data  Rato  Selection 

Up  to  78  dBm  (dual  chain) 

0  77  d8,  in  1  dB  steps  Automatic  TPC  wttli  configurable  FlRP  limit 


80  691Z 

40  MMr 

20  MHz 

TXPOWFR 

MC  SO  28 

MCSO  28 

MCSO  29 

MCS9  21 

MCS9  22 

MCS8  25 

RX  SENSITIVITY  (Per-WN 

MCSO  89 

MCSO  93 

MCSO  94 

MCS9  68 

MCS9  71 

MCS8  74 

THROUGHPUT 

Upto  633  Mbps 

Up  to  324  Mbps 

Up  to  137  Mbps 

OTHER 


Dynamic  Channel  Selection  (DCS)  based  on  interference  detection  Dynamic  Frequency  Selection  (DFS)  based  on  radar  signature  Automatic  Transmit  Power  Control  (ATPC)  with  FlRP  Wnfl  support 


ANTENNA 


OB  10100  EPA 
QB  1015OEPR 
OB-IOISO-EPL 


Two  N-type  Connectors  with  built  in  Surge  Proli'dion 
Integrated  2*2  MIMO  22d8l  Dual  Polarized  1  foot  Panel  Antenna 
Integrated  2*2  MIMO  28dB)  Dual  Polarized  2  feet  Panel  Antenna 


REMOTE 

SNMP 

OTHER 


Telnet  and  SSH  Web  GW  and  SSL/TIS.  TETP,  SNMPr3 

SNMP  etw3c-v3,  RFC-t213.  RFC-121S.  RFC-2790,  RFC-7571,  RFC-3417.  RFC-3414.  Pnvate  MIR 
Systog.  sFiow'  agent.  SNTP  and  local  unw>.  Spectrum  analyzer 


Source:  Proxim  Wireless  (2016). 
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APPENDIX  D.  SUPPLEMENTARY  QUALNET  APPLICATIONS 


The  File  Transfer  Protocol  (FTP)  application  uses  network  traces  to 
determine  the  size  of  the  file  sent  between  a  client  and  server.  It  is  based 
on  the  RFC  959  standard.  It  differs  from  the  FTP  Generic  model  used  in 
the  scenarios  due  to  its  randomization.  The  size  and  number  of  files  sent 
can  be  randomly  determined  by  the  tcplib. 

The  Hypertext  Transfer  Protocol  (HTTP)  application  simulates  single  TCP 
connections  between  web  servers  and  clients.  The  application  can  model 
the  client-server  functionality  between  nodes  and  can  also  simulate  an 
FQDN  through  the  specific  configuration  of  the  server  node  in  the 
QualNet  application  file.  Nodes  can  be  automatically  configured  in  the 
simulation  by  designating  them  as  HTTP  servers. 

The  Lookup  Traffic  Generator  simulates  ping  commands  and  DNS 
lookups  from  one  node  or  IP  address  to  another.  It  can  be  configured  with 
predetermined  start  and  stop  times  or  left  to  run  throughout  the  entire 
scenario,  similar  to  the  CBR  application. 

The  Multicast  Constant  Bit  Rate  (MCBR)  Generator  is  useful  for  testing 
the  network’s  capability  to  run  applications  reliant  upon  steady  time 
synchronization,  such  as  on-demand  services  —  i.e.,  streaming  video  or 
VoIP.  The  application  is  typically  configured  to  send  items  to  a  multicast 
address. 

The  Variable  Bit  Rate  (VBR)  application  is  similar  to  the  CBR 
application.  It  is  useful  for  injecting  background  traffic  over  a  specified 
time  interval.  The  user  determines  a  fixed  item  size  to  send  from  one  node 
to  another  at  random  intervals  between  the  start  and  stop  time  of  the 
simulation. 

Source:  Scalable  Network  Technologies  (20 14f) 
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APPENDIX  E.  SUPPLEMENTARY  QUALNET  STATISTICS 


802.11  a/g  PHY 

Signals  locked 

(signals) 

Number  of  signals  locked 

on  by  PHY 

802.11  a/g  PHY 

Signals  received  with 

errors  (signals) 

Number  of  signals  received 

with  errors 

802.11  a/g  PHY 

Signals  received  with 

interference  (signals) 

Number  of  signals  received 

with  interference 

802.11  a/g  PHY 

Signals  sent  to  mac 

(signals) 

Number  of  signals  sent  to 

MAC 

802.11  a/g  PHY 

Time  spent 

transmitting  (seconds) 

Time  spent  in  transmitting 

signal 

802.11  a/g  PHY 

Time  spent  receiving 

(seconds) 

Time  spent  in  receiving 

signal 

802.11  a/g  PHY 

Average  transmission 

delay  (seconds) 

Average  transmission 

delay 

802.11  a/g  PHY 

Utilization 

(percent/ 100) 

Total  utilization 

802.11  a/g  PHY 

Average  signal  power 

(dBm) 

Average  signal  power 

802.11  a/g  PHY 

Average  interference 

(dBm) 

Average  interference 

802.11  MAC 

CTS  packets  sent 

Total  number  of  CTS 

packets  send  to  the 

channel. 

802.11  MAC 

RTS  packets  sent 

Total  number  of  RTS 
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packets  send  to  the  channel 

802.11  MAC 

ACK  packets  sent 

Total  number  of  ACK 

packets  sent. 

802.11  MAC 

RTS  retransmissions 

due  to  timeout 

Total  number  of  RTS 

retransmissions  due  to 

timeout 

802.11  MAC 

Packet  retransmissions 

due  to  ACK  timeout 

Total  number  of  data 

retransmissions  due  to  no 

ACK  received 

802.11  MAC 

Packet  drops  due  to 

retransmission  limit 

Total  number  of  packets 

dropped  due  to  retry  limit 

exceeds 

AODV  Network 

Number  of  RREQ 

Packets  Initiated 

Number  of  route  request 

messages  initiated 

AODV  Network 

Number  of  RREQ 

Packets  Retried 

Number  of  route  requests 

resent  because  node  did  not 

receive  a  route  reply 

AODV  Network 

Number  of  RREQ 

Packets  Forwarded 

Number  of  route  request 

messages  forwarded  by 

intermediate  nodes 

AODV  Network 

Number  of  RREQ 

Packets  Initiated  for 

local  repair 

Number  of  route  requests 

initiated  for  local  repair 

AODV  Network 

Number  of  RREQ 

Packets  sent  for 

alternate  route 

Number  of  route  requests 

initiated  for  finding 

alternate  routes 

AODV  Network 

Number  of  RREQ 

Number  of  route  requests 
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Packets  received 

received 

AODV  Network 

Number  of  Duplicate 

RREQ  Packets 

received 

Number  of  duplicate  route 

requests  received 

AODV  Network 

Number  of  RREQ 

Packets  dropped  due 

to  TTL  expiry 

Number  of  route  requests 

dropped  due  to  TTL 

expiration 

AODV  Network 

Number  of  RREQ 

Packets  discarded  for 

blacklist 

Number  of  route  request 

dropped  due  to  the 

previous  hop  been  in 

blacklist  table 

AODV  Network 

Number  of  RREQ 

Packets  received  by 

Destination 

Number  of  route  requests 

received  by  the  destination 

AODV  Network 

Number  of  RREP 

Packets  Initiated  as 

Destination 

Number  of  route  replies 

initiated  from  the 

destination 

AODV  Network 

Number  of  RREP 

Packets  Initiated  as 

intermediate  node 

Number  of  route  replies 

initiated  as  an  intermediate 

hop 

AODV  Network 

Number  of  RREP 

Packets  Forwarded 

Number  of  route  replies 

forwarded  by  intermediate 

hops 

AODV  Network 

Number  of  Gratuitous 

RREP  Packets  sent 

Number  of  gratuitous  route 

replies  sent 

AODV  Network 

Number  of  RREP 

Packets  Received 

Number  of  route  replies 

received  by  the  node 
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AODV  Network 

Number  of  RREP 

Packets  Received  for 

local  repair 

Number  of  route  replies 

received  for  local  repair 

AODV  Network 

Number  of  RREP 

Packets  Received  as 

Source 

Number  of  route  replies 

received  as  data  source 

AODV  Network 

Number  of  Hello 

message  sent 

Number  of  hello  messages 

sent 

AODV  Network 

Number  of  Hello 

message  received 

Number  of  hello  message 

received 

AODV  Network 

Number  of  RERR 

Packets  Initiated 

Number  of  route  error 

packets  initiated 

Source:  Scalable  Network  Technologies  (2014f). 
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APPENDIX  F.  UNMANNED  SYSTEM  SPECIFICATIONS 


Seafox  Unmanned  Surface  Vessel 


Source:  Naval  Postgraduate  School  (n.d.b.) 

Communications 

•  440MHz  command  and  control  link 

•  2.4GHz  wireless  mesh  network 

Sensors 

•  Dual  BlueView  obstacle  avoidance  sonar  (2D) 

•  Horizontal  plane  and  vertical  plane 

•  Independent,  computer-controlled  pan/tilt  actuators 

•  Remote  or  computer-controlled  actuation  (deploy /retract) 

•  Dual  HoodTech  Stabilized  Pan/Tilt/Zoom  video  camera  turrets 

•  Elector-optic  camera 

•  Infrared  camera 

•  Six  fixed  wide  angle  video  navigation  cameras 

o  (3)  Daylight  (color) 

o  (3)  Low  Light  (black  &  white,  lowlight  (3) 
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RQ/MQ-8  Fire  Scout  Unmanned  Aerial  Vessel 


Source:  Parsch  (2009) 


Technical  Specifications 

•  Length  Folded  30.03  ft  (9.2  m) 

•  Rotor  Diameter  27.50  ft  (8.4  m) 

•  Height  9.42  ft  (2.9  m) 

•  Gross  Weight  3,150  lbs  (1,428.8  kg) 

•  Engine  Rolls-Royce,  Model  250-C20W 

•  Speed  125+  knots 

•  Ceiling  20,000  ft  (6.  lkm) 

•  Total  Flight  Time  with  Baseline  Payload  8+  hours 

•  Total  Flight  Time  with  500  lb  Payload  5+  hours 

•  Payloads  600  lbs  capacity 

o  EO  /  IR  /  LD  BRITE  Star  II 
o  UHF  /  VHF  Comm  Relay 
o  COBRA  Mine  Detector 
o  Airborne  Comm  Package  (Pineda,  2009) 
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